On 08/26/11 13:56, Ian Lance Taylor wrote:
Bryan Ischo<bryan@xxxxxxxxx> writes:
Thank you for your reply. So just to be clear, are you saying that I
would configure gcc --with-sysroot=DIR, and then at runtime I can do:
$ mv DIR DIR.moved
$ /some/random/path/to/gcc
And that gcc, which was installed in a place that had nothing to do
with DIR, will somehow know that I moved DIR? How does it do that?
Yes, that is what I am saying. The key is that gcc itself is under
DIR--it's in DIR/bin. It looks at argv[0] to see where it was run from.
Ian
Now I'm really confused. My example doesn't have gcc under DIR; it's
under /some/random/path/to/gcc. sysroot is for header files and
libraries, or at least that's how it's described in all documentation I
have read. Here is what the gcc manual says about --sysroot:
"|--sysroot=|dir
Use dir as the logical root directory for headers and libraries.
For example, if the compiler would normally search for headers in
/usr/include and libraries in /usr/lib, it will instead search
dir/usr/include and dir/usr/lib. ..."
Why would gcc be under sysroot if sysroot is for include files and
libraries?
Also, isn't looking at argv[0] to see where an executable was run from
generally bad practice on Unix? You can't always know with certitude
where a program was run from just by looking at argv[0], and the
techniques that are often used to take argv[0] and turn it into an
absolute path are typically nonportable, not guaranteed to work, and
generally suspect. Or at least that's how I understand it ...
And finally, for a cross-compiler, how would gcc ever be under DIR
anyway? DIR is the root of a subtree containing include files and
libraries for the $TARGET platform, whereas gcc itself is run on the
$HOST platform; it is counter-intuitive to me that a directory
containing include files and libraries for $TARGET platform would have
binaries under bin meant to run on $HOST platform ...
Thanks,
Bryan
