Adapting LFS SVN for multilib

Ryan Oliver ryan.oliver at
Tue Jan 13 07:14:17 PST 2009

Greg Schafer wrote:
> 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.
See below
>  There is much less
> hackery involved if you install into a single prefix ie: /tools.
Except you then are placing tools compiled and linked against the host 
in the directory that is supposed to be clean.
>  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.
Incorrect. The initial point of installing into a separate directory 
(for myself, the choice was my home directory) was to be able to
a) re-use the toolchain.(so as to use distcc when building on slow systems)
b) ensure that /tools never sees any pollution from binaries, libraries 
or includes of packages compiled against the host system
c) Allow for easy restarting of the build.
> In summary, $prefix is king, and I refuse to mess with it.
Except $prefix is not used in a non-sysroot cross-compiler.

At present your cross-toolchain neither locates includes anywhere (you 
would have to set CROSS_INCLUDE_DIR via editing CROSS_SYSTEM_HEADER DIR 
in for that to happen without resorting to a specs edit), or 
locates libraries or startfiles (which you misuse -B for).

The native toolchain is finding headers via LOCAL_INCLUDE_DIR, not 
PREFIX_INCLUDE_DIR (local prefix always comes first).

It isn't exactly finding libraries directly via $prefix either (it 
calculates it from gcc's location in the filesystem via gcc_exec_prefix, 
which relocates with the toolchain)
Thats what your forward ported patch from the 2.95.3 days is there for 
(make it search $prefix).

Directly altering the macros which define include and library search 
paths allows you to install the toolchain into any prefix you want (or 
relocate it anywhere you want after install), and still have the 
toolchain work exactly as expected... just like a standard native 
compiler does.

>>   * 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.
No I am not. You can continue to install the updated ld-new with the 
search path in the linker scripts set /lib and /usr/lib etc
-rpath-link accomplishes the same thing by altering ld's default search 
path, thereby locating required libraries not explicitly defined during 
the link stage in the specified path.

More below
>  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.
Thats your choice.

Posted method was put there to show you how to do it without using 
heinously evil undocumented (if you dont count the source) specs.

Use of LIBRARY_PATH can be replaced by altering specs (specifically 
md_startfile_prefix_1) just as we used to edit the unmentionable 
Frankly, editing of specs is where most people stuff the build up, the 
less done there the better.

Setting the fully documented LIBRARY_PATH env var and using it for its 
documented purpose does not in any way upset the build even if you 
forget to unset it later either..

> 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
And never will. If it did it would totally break the gcc and glibc 
builds (the only places you will ever find it used).
Test it yourself, its a one character edit in gcc.c to make it multilib 

If you want I can create a patch to generate another switch to gcc (my 
pref is -X) that would have the same priority as -B except would be 
multilib aware
(its not rocket science)
> 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.
It is there for educational value. You have the choice to build either 
32bit or 64bit, whatever floats your boat.
It takes no extra time or effort to do the job properly..
>> 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.
The sysroot build is "misused" in pretty much the same way the original 
native plfs toolchain was "misused".
ie: include, library and dynamic linker search paths are altered to 
search in /tools (except of course that the toolchain will only ever 
look inside the sysroot ${LFS}).
Sysroot build allows the use of pretty much all the same macro edits 
available to a native toolchain.

I still have no issues using startfile_prefix_spec and altering 
CROSS_INCLUDE_DIR for a non-sysroot cross-compiler
(and those two things are ALL you have to alter library and include 
search paths respectively in a non-sysroot cross-compiler without 
resorting to a specs edit).

Sysroot build method apart from the obvious advantages, frankly, has the 
added advantage of deflecting FUD.

Best Regards

More information about the lfs-dev mailing list