Breakage with bleeding edge host toolchains (Fedora)

Bryan Kadzban bryan at
Wed Feb 28 04:15:04 PST 2007

Dan Nicholson wrote:
> Actually, it's not so bad since you can always run `chmod a+x 
> /tools/bin/ld' safely. Maybe this is the right way to go. I guess
> it's more preference that I like the other way, but this would seem
> to do the trick, too.

Well, I realized there's a problem with it:  The new gcc can't do any
feature tests on our ld if our ld can't be executed.

I think that's a showstopper for that method.  ;-)

> The old Ryan/Greg argument has to do with Greg's preference of using 
> -B/usr/lib/ to force gcc to find the glibc startfiles in /usr/lib.

Oh, OK.  Yeah, that should work according to the docs (subprograms,
startfiles, and include files are all searched for in the -B path --
although include files are searched for in an include/ subdirectory),
but it does seem to be a slightly odd way to use it.

> For this case, it looks like there's a couple different ways we can 
> attack this. But I think we agree that this is a good thing to do.

Oh, yes, I think we need to be buildable from newer distros.

There are actually a few other ways of doing that too: we could upgrade
binutils to handle the new flags.  Or we could build gcc twice (once
before binutils -- and modify the new compiler's specs -- so it doesn't
use the new flags, and once after binutils to get the final compiler
that we get now).  Building gcc twice will take a lot longer though, and
binutils updates would need a lot of testing.  Given the alternatives, I
think -B is a fairly easy way to do it (but I'd vote for COMPILER_PATH
if it's supported properly by gcc 2.95.3 -- I have no idea whether it is).

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 252 bytes
Desc: OpenPGP digital signature
URL: <>

More information about the lfs-dev mailing list