Breakage with bleeding edge host toolchains (Fedora)
dbn.lists at gmail.com
Tue Feb 27 15:57:13 PST 2007
On 2/27/07, Bryan Kadzban <bryan at kadzban.is-a-geek.net> wrote:
> Dan Nicholson wrote:
> > Greg came up with a pretty good solution for DIY (IMO). Basically, by
> > passing CC="gcc -B/usr/bin/" during binutils-pass1 and gcc-pass1,
> > gcc will continue to use the host linker until we get our gcc built.
> Why not set our new linker to not be executable (that is, chmod a-x)
> until pass1 gcc is built? That way we don't accidentally affect
> anything else.
I suppose that would probably work. It opens the door that people
would forget to make it executable again. But, that's probably no more
error prone than expecting people to pass the correct -B arg to gcc.
> The gcc specs file hardcodes a linker name of "collect2", but collect2
> is a program from gcc itself. It runs a bunch of code, and at some
> point finally executes DEFAULT_LINKER if that was set during gcc's
> configure script (--with-ld). If DEFAULT_LINKER isn't set, then it
> searches the $PATH for an executable program named "ld".
> So if our ld in /tools/bin isn't executable, it shouldn't find it.
> Or how about $COMPILER_PATH? If we set that to have /usr/bin listed
> before /tools/bin, that might also work. This will affect more than
> just ld -- it will affect ld, (g)as, and any other subprogram run by
> gcc. But OTOH, each of these programs may have the same issue in the
This is essentially the same as passing -B. Try out these commands:
$ gcc -print-search-dirs | grep '^programs:'
$ gcc -B/usr/bin/ -print-search-dirs | grep '^programs:'
$ COMPILER_PATH=/usr/bin gcc -print-search-dirs | grep '^programs:'
The second and third outputs appear the same on my system.
More information about the lfs-dev