Jeremy Huntwork wrote: > I have been adapting Ryan's methods to LFS because I think that there > are certain improvements over what is currently in trunk. Specifically:
A quick glance shows you are bringing in one of CLFS's ugliest design faults - the bizarre `/cross-tools' prefix. Let me explain: By installing stuff into different prefixes, you are forced to butcher the GCC source to coax it into searching the right places. Why? Because many of the toolchain search paths are keyed off of $prefix. There is much less hackery involved if you install into a single prefix ie: /tools. One of the rationales for CLFS introducing the `/cross-tools' thing was apparently to prevent the over-writing of Pass 1 files with Pass 2. This no longer happens with current DIY/LFS because Pass 1 is now a cross toolchain. The other rationale was to keep some separation. Personally, I don't buy this argument. The whole thing is temporary anyway, and the cost of ugly hackery far outweighs any tidyness benefit. In summary, $prefix is king, and I refuse to mess with it. > * No need for ever specifying '-B/tools/lib' Sure. But at what cost? It appears you haven't tackled Chapter 6 yet. Ryan appeared to be pushing `-rpath-link' and/or global toolchain ENV VARS such as LIBRARY_PATH. The hypocrisy here is that, back when Ryan and myself worked on the previous build method, we *both* ruled these out as unsuitable for the masses. I refuse to use arcane linker switches and global toolchain ENV VARS in any build recipe of mine. I might also remind folks that `-B' is the documented user interface to GCC search paths. It's true that it currently doesn't respect multilib os dirs ie: it doesn't search `../lib64', `../lib' etc. But guess what, IT DOESN'T MATTER! Folks here apparently haven't grasped that when building a 64-bit multiarch toolchain, a fully functional 32-bit toolchain is not needed until well after the Ch 6 toolchain is in place. > The gcc devs have said that the sysroot methodology is the 'correct path > forward' for cross compiling. Yes, but you're missing the point that the "inhibit_libc mini GCC" we build in GCC Pass 1 is not the typical cross compiler the gcc devs are talking about. And I can assure you, they are most definitely *NOT* talking about the kind of misused sysroot you're proposing here. I'm honestly surprised that Ryan has (ab)used sysroot in such a fashion. As much as it pains me to say, the "CLFS Sysroot" build is much closer to the mark as an example of a cross toolchain for typical embedded use. Also, I hope your not basing your sysroot justification on an off-handed comment from 1 junior GCC dev in a GCC bug report of mine. That would be rather foolish to say the least. > To me, this is the way forward for 7.0. To me, you're completely off track. Good luck. 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
