Final toolchain dir
ANDY KENNEDY
ANDY.KENNEDY@adtran.com
Mon Mar 28 17:43:00 GMT 2011
> I have an option here, that implies some union mounts, and can ease
> the
> stuff (absolutely untested, product of my insane brain!), but that
> does
> not cover the SDK case you and Javier need to handle:
>
> - create a directory that will be used to _hold_ the staging area
> - create another directory, that will be used _as_ the staging area
> - union mount the sysroot as a RO branch and the real staging area
> (ie the first created dir above) as a RW branch onto the final
> staging area (the second dir created above).
> - rename all the toolchain tools (eg. tuple-gcc, tuple-g++, tuple-
> ld
> and so on...) and provide wrappers to replace them
> - have the wrapper always include --sysroot=/the/union/mount/point
> - use /the/union/mount/point as DESTDIR when installing
> - once eveything is installed, unmount the union, and use the real
> staging area (the first dir created above) as the source for
> populate
> - use populate as previously explained.
>
> That way, you ensure that:
> - the sysroot is not poluted with secondary libs (eg. zlib, Qt...)
> - the apps always find the system libs *and* the secondary system
> libs
> thanks to the --sysroot option forced by the wrappers
> - the target directory does not contain headers and static stuff
> from
> the sysroot
>
> However:
> - you have to cleanup the real staging area of the headers and
> static libs
> and other stuff that have no say in the target file system
If I ever start drinking I may read this again to see if it makes
sense to me then. For now, however, I think I'll continue to do it
the wrong way as I tend to be lazy, find the easiest way out, and
that seems really script code involved ;).
Andy
--
For unsubscribe information see http://sourceware.org/lists.html#faq
More information about the crossgcc
mailing list