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).
signature.asc
Description: OpenPGP digital signature
-- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
