Matthew Burgess wrote: > Now, if we can simplify gcc4's SPECFILE assignment, that's great.
Um, the suggestion was to use the correctly documented switch, not to go and completely redo the specs handling :-) Of course, you can do that if you want to. I've done exactly that for the DIY build ie: developed procedures that work with both GCC-3.4.x and GCC-4.x. But unlike LFS, the DIY build is targeted at scripters, which requires a different set of considerations. <slightly OT> IMHO, the LFS build cmds must: - be easily typed on the interactive shell command line - minimize chances of error at the critical build stages This is because LFS aims to teach, and a large percentage of its audience are newbies wanting to learn. </slightly OT> > However, > as Greg mentions above, -print-file-name is only documented to print out > library files that would be linked to. As we'd be asking it to print out > a non-library file, surely that's just as undocumented and therefore prone > to breakage as our current method, no? Maybe. But I specifically covered that point in the opening post. Try grepping the Binutils and Glibc sources for '-print-file-name'. Both pkgs use the *documented* switch to find things that are not libraries eg: specs, startfiles, internal include dir, etc. The documented switch is never going to break on non-libs while ever those other pkgs are relying it IMHO. The difference for LFS is that it's using an *undocumented* switch that happens to work by chance. Regards Greg -- http://www.diy-linux.org/ -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
