Redux: Question about gcc/binutils relocatability

[Steven W. Orr]

On Thursday, Dec 7th 2006 at 16:57 -0500, quoth Steven W. Orr:

=>On Thursday, Dec 7th 2006 at 13:23 -0500, quoth Paul Lussier:
=>
=>=>"Steven W. Orr" <steveo at syslang.net> writes:
=>=>
=>=>> No, I'm not asking about whether the generated code is
=>=>> pc-relocatable. I'm asking if the arg to the --prefix option at
=>=>> configure time stops the compiler from working if the tools are
=>=>> installed in a different location. Last time I looked, that was an
=>=>> issue but now I'm wondering.
=>=>>
=>=>> If it's no longer an issue then I have to assume that gcc figures out
=>=>> where its components are by figuring out what direectory its binary is
=>=>> located in. Can someone please 'splain dis won to me? I am verstumpt.
=>=>
=>=>I'm not quite sure what you're asking.  Are you trying to build
=>=>binutils, or gcc? --prefix should allow you to place something
=>=>anywhere you want it.  The compiler probably needs to be able to
=>=>*find* it once you've installed it, which means that the arg to
=>=>--prefix needs to be in your path, or provived to the compiler when it
=>=>is run so it knows where to find them.
=>=>
=>=>For example, if you're going to build/install binutils like this:
=>=>
=>=>  ./configure --prefix=/usr/local/random/path/put/bin/utils/here
=>=>
=>=>You need to augment your $PATH with:
=>=>
=>=>  PATH=$PATH:/usr/local/random/path/put/bin/utils/here/bin
=>=>
=>=>Or, when calling gcc, do something like:
=>=>
=>=>  PATH=$PATH:/usr/local/random/path/put/bin/utils/here/bin gcc ....
=>=>
=>=>When calling gcc (which can be accomplished by setting that path in a
=>=>Makefile).
=>=>
=>=>Does that help?
=>
=>Almost, but not quite. A while ago (given my advancing old age) the spec 
=>file (usually found in $prefix/lib/gcc/i386-redhat-linux/4.0.2 would list 
=>where the compiler was expected to find all of the needed components, like 
=>as, ld, cpp, etc. Now I see no spec file and gcc seems to not care where 
=>it gets installed even if that directory is different from $prefix. It 
=>seems like the gcc build doesn't care where it runs from and that $prefix 
=>is only used by make install. The odd thing (as if this isn't odd enuff) 
=>is that if you run strings on the gcc binary you will see the entire 
=>configure commandline.
=>
=>What I was asking for was for confirmation. 

Ok. here's what I came up with: From the excellent manual...

--------------
`-BPREFIX'
     This option specifies where to find the executables, libraries,
     include files, and data files of the compiler itself.

     The compiler driver program runs one or more of the subprograms
     `cpp', `cc1', `as' and `ld'.  It tries PREFIX as a prefix for each
     program it tries to run, both with and without `MACHINE/VERSION/'
     (*note Target Options::).

     For each subprogram to be run, the compiler driver first tries the
     `-B' prefix, if any.  If that name is not found, or if `-B' was
     not specified, the driver tries two standard prefixes, which are
     `/usr/lib/gcc/' and `/usr/local/lib/gcc/'.  If neither of those
     results in a file name that is found, the unmodified program name
     is searched for using the directories specified in your `PATH'
     environment variable.

     The compiler will check to see if the path provided by the `-B'
     refers to a directory, and if necessary it will add a directory
     separator character at the end of the path.

     `-B' prefixes that effectively specify directory names also apply
     to libraries in the linker, because the compiler translates these
     options into `-L' options for the linker.  They also apply to
     includes files in the preprocessor, because the compiler
     translates these options into `-isystem' options for the
     preprocessor.  In this case, the compiler appends `include' to the
     prefix.

     The run-time support file `libgcc.a' can also be searched for using
     the `-B' prefix, if needed.  If it is not found there, the two
     standard prefixes above are tried, and that is all.  The file is
     left out of the link if it is not found by those means.

     Another way to specify a prefix much like the `-B' prefix is to use
     the environment variable `GCC_EXEC_PREFIX'.  *Note Environment
     Variables::.

     As a special kludge, if the path provided by `-B' is
     `[dir/]stageN/', where N is a number in the range 0 to 9, then it
     will be replaced by `[dir/]include'.  This is to help with
     boot-strapping the compiler.
-------------

Here's the deal. I build a gcc/binutils with --prefix set to $x. After 
it gets installed in $x, someone else comes along and copies it to $y. It 
runs just peachy (or so it seems). At execution time, $y/bin has been 
added to PATH. My claim is that gcc without a -B option is the same as 
running gcc -B $x. So if I run gcc from $y I run the risk of using stuff 
from /usr/lib/gcc that I really should not be getting.

So, while gcc may be doing the right thing 99.44% of the time, is it not 
clear that doing things like this is sloppy at best? Or am I just too 
fussy?

-- 
Time flies like the wind. Fruit flies like a banana. Stranger things have  .0.
happened but none stranger than this. Does your driver's license say Organ ..0
Donor?Black holes are where God divided by zero. Listen to me! We are all- 000
individuals! What if this weren't a hypothetical question?
steveo at syslang.net