toolchain's sysroot via environment

Mike Frysinger vapier@gentoo.org
Fri Jul 16 18:39:00 GMT 2010


On Thursday, July 15, 2010 20:08:04 Arno Schuring wrote:
> Regarding your first question: that's not possible - the sysroot paths
> are compiled-in. If it were just the paths, if would not be much of a
> problem - but the toolchain components (compiler, linker) are also
> compiled differently based on the libraries available in the sysroot.

the *default* sysroot paths are compiled in, but you can change it on the 
command line on the fly

> First off, what the gcc toolchain calls a "sysroot" is not necessarily a
> full "system". The term "libroot" would be more accurate, because it
> only used to find the necessary files to cross-compile: headers and
> libraries. And of these files, only the shared libraries are needed at
> runtime (cue static linking and libnss debate).
> 
> When dealing with cross-compiling, you always have multiple copies of
> the system files available. First, you have the location where the
> cross-toolchain gets its information from. Let's stick with existing
> convention and call it SYSROOT. Second, you have the actual system that
> is (or will be) running the executables you are creating. Let's call it
> the TARGET (no surprise, right?). You actually do not /need/ more than
> that: you can just install all your files into sysroot, tar it up and
> drop all your files on the target. But I've found it very convenient,
> especially with slimmed-down embedded targets, to keep around a third
> copy in which to do all the hard work (configuring, pruning). Let's use
> glibc's INSTALL_ROOT for this intermediate tree.

this is overly complicated.  simply keep the sysroot as a normal system and 
then you only extract the necessary files for the target.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://sourceware.org/pipermail/crossgcc/attachments/20100716/0f0d2a8f/attachment.sig>


More information about the crossgcc mailing list