Matthew Burgess wrote: > In the interests of getting this issue off your/our plates I'd say we > choose whatever method is most suited to LFS as it is now. That is, > whichever works on x86 native compilations and is officially > supported/documented upstream. Yes, I understand people's desires to > keep LFS' & CLFS' instructions as close as possible, but given the very > different purposes of the two toolchains between those books I'd say > this is one point at which it's reasonable to expect the instructions to > differ.
And the more this is discussed, the more I'm inclined to agree. That being said, what is currently in trunk agrees with this standpoint. From all I can tell from the documentation '-B' will give us what we need, and it's only used for two packages, binutils and gcc in chapter 6. The only things in trunk currently that might need changing, then, are: 1) Don't use a wrapper for gcc as seen in the readjusting section. I'm not sure about this one. The alternative to that would be to use 'CC="gcc -B/usr/lib/ -B/usr/bin/"' on the sanity test, the binutils configure, and the gcc configure. 2) The libgcc_s.so symlink shouldn't be necessary if we're not using the *startfile_prefix_spec. 3) We could replace the ld's as per the instructions in my patch instead of making a symlink as is in the current book. Advantage is that there is no possibility of the old ld being used and that we shouldn't have to insert a '-L/usr/lib' in the specs file. Disadvantage is that it possibly corrupts /tools again, and we'd have to deal with that. Otherwise, we could leave trunk as it currently is, get some major testing done on it, and see how things progress. -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
