Adapting LFS SVN for multilib
gschafer at zip.com.au
Tue Jan 13 04:21:15 PST 2009
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.
More information about the lfs-dev