best practice for sysroot

[Enrico Weigelt]

Hi folks,


I'm making heavy use of sysroot builds (using it for cleanroom builds,
even when staying on the same platform) and I've already done quite
a lot of fixes (or better: hacks) to get a lot of packages running
with sysroot. But still I haven't got a general modeling for that. 

For example: ssh imports ssl.

I've noticed that the build fails come from completely wrong pathes
and so incompatible libc parts (ie missing xxx_fini symbols). 
The problem is that autoconf's detection routines add things like
-L/usr/lib/ to the LDFLAGS, so we run into conflicts between host
and sysroot'ed target.

My first try was to put an = in front of the library and include path.
But this breaks the SSL detection routine, since it doesnt know 
that = must be expanded to the sysroot to access the filess.

I've now solved it by simply passing the full path to ssl, including
sysroot prefix to ssh. This works on my platform (i686-gnu-linux), 
but will probably break others where the path to the libraries is
relevant (ie on some platforms the -R option of ld is used, which 
AFAIK tells it where to find the library at runtime).

The best solution seems to pass the sysroot path to the buildsystem
(ie configure or gmake) and expand the sysroot symbol (ie =) when
needed. 

Does anything speak against using a SYSROOT environment variable
for this ? Or something else we have to care about ?


cu
-- 
---------------------------------------------------------------------
 Enrico Weigelt    ==   metux IT service

  phone:     +49 36207 519931         www:       http://www.metux.de/
  fax:       +49 36207 519932         email:     contact@metux.de
  cellphone: +49 174 7066481
---------------------------------------------------------------------
 -- DSL ab 0 Euro. -- statische IP -- UUCP -- Hosting -- Webshops --
---------------------------------------------------------------------

------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sources.redhat.com