This is the mail archive of the crossgcc@sources.redhat.com mailing list for the crossgcc project.

See the CrossGCC FAQ for lots more information.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: best practice for sysroot


* Robert Schwebel <robert@schwebel.de> wrote:

Hi,

> PTXdist has a generic mechanism to apply patches to a packet before
> running it's prepare stages. The patches are either taken from our patch
> server or from a local directory. You could do something similar for
> sysroot. 
My distro buildsystem (Briegel) also has such a facility. It can apply
version dependent patches after unpacking the sourcetree. 

You maybe like to have a look at the patches I've collected:

    rsync://nibiru.metux.de/metux-patches/

<snip>

> By the way - what _is_ sysroot? 
hmm, good question ;-P

I'm using a sysroot'ed crosscompiler for cleanroom-builds which should
not use anything but the stuff in the jail. Many packages (ie openssh) 
still fail, since they pass things lile -L/usr/ssl/lib/ to ld, so it 
really takes the libs from there instead of {SYSROOT}/usr/lib. 

Now I'm thinking about two different approaches to solve this:

a) patch the buildsystems of individual packages to use a $SYSROOT
   variable and work entirely within this directory. All pathes, also
   those supplied to configure are always relative to $SYSROOT. 
   This makes a lot of work (fixing many buildscripts), but seems 
   to be quite intuitive. But it also brings the problem that probably
   some packages need stuff outside of $SYSROOT, ie stuff from other
   packages which are not installed in the sysroot, but linked against
   (ie static libraries ?)
   
b) code a frontend for the toolchain commands, which translate the 
   absolute pathes to point within $SYSROOT. We must be careful not
   to touch relative pathes, since there maybe necessary pathes 
   (includes + libs) within the sourcetree.
   So we dont need any changes in the packages build stuff an we 
   also do not have to cover in the configure parameters about 
   sysroot'ing (ie passing pathes within $SYSROOT instead of abolute
   pathes to configure). 
   Probably this does not solve all situations, ie some stupid 
   buildsystem could supply absolute pathes within its own sourcetree.
   It also makes trouble as soon as the application tries to touch
   files outside of the sourcetree in other ways than with the 
   masqueraded toolchain commands.
   
c) all pathes starting with the sysroot symbol (ie "=") are translated
   to be realtive to $SYSROOT. If an external program is called to 
   retrieve installation pathes of some lib (/usr/bin/foo-config/ or
   pkgconfig query), its output has to be parsed an the SYSROOT 
   prefix is added. (We probably need a way for explicitly overriding
   this behaviour in certain situations ... no idea if this is 
   really needed someday)
   This solution seems to be the most cleanest and most portable way
   and should (IMHO) be the for all packages to go, so we probably 
   could fix autoconf (btw: is autoconf more than a collection of bugs ?)
   to solve this problem more generally.

I'd prefer version c).


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]