Breakage with bleeding edge host toolchains (Fedora)
bryan at kadzban.is-a-geek.net
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...
Size: 252 bytes
Desc: OpenPGP digital signature
More information about the lfs-dev