Adapting LFS SVN for multilib

[Ryan Oliver]

Greg Schafer wrote:
> Ryan Oliver wrote:
>
>   
>> We all know what sysroot is for.
>>
>> All sysroot does is shift the search paths underneath the sysroot, no
>> more, no less.
>>     
>
> Well, yes. But Sysroot is specifically for *root* file systems. Here's
> another data point from the GCC man/info/web docs:
>   

>  "--sysroot=dir
>     *Use dir as the logical root directory for headers and libraries*. _For_
>     _example_, *if* the compiler would *normally* search for headers in
>     /usr/include and libraries in /usr/lib, it will instead search
>     dir/usr/include and dir/usr/lib*"
>   
<Emphasis is mine>.

Don't mix up explanation with example.

This merely re-enforces the point I made above.

> You're using sysroot on a non-root file system.
You obviously don't understand the meaning of _logical root directory_.

FHS standard under the _logical root directory_ is not implied.

>  Which is why you are
> forced to hack the source to make it search only the dirs that you want.
>
>   

Exactly as was done for plfs, lfs and DIY.

Hell, you are already hacking *_THE EXACT SAME MACROS_*.

> I repeat - You're abusing the sysroot feature and setting a poor example.
>
>   

Repeating a statement does not make it true.

I am using the sysroot feature for a target system root.
I am then overriding the standard macros for specifying where to search 
for includes and startfiles, which is a completely separate thing.


...


And here I thought changing the documented macros for default include 
and library search path handling instead of using an undocumented (if 
you dont count the source) spec and CROSS_INCLUDE_DIR would stop the FUD 
storm.

Methinks the difference between
"l337 super new mega clfs-killing second-coming toolchain build method 
!!!11!!1!"
and
"GAH OH NOES gcc source edits, sysroot misuse, FUD FUD unsubstantiated FUD"
is merely that the author was not Greg Schafer.

I put this build together *solely to prove a point* after attempting to 
give *you* some subtle guides on how *you* could improve *your* build.

http://linuxfromscratch.org/pipermail/lfs-dev/2008-December/062469.html

and your response

http://linuxfromscratch.org/pipermail/lfs-dev/2008-December/062472.html

Hell, I even "fixed" up your "-B binary search path doesn't use 
multilibs" problem for you.
I've offered to even "fix" up the "broken gcc -specs switch handling 
"bug"" for you (even easier "fix" than the -B multilib handling).

It is astounding that you have for so long been complaining about 
multilib -B handling (it is unnecessary and is quite frankly wrong) and 
that
"startfile specs are broken because I can't override them from a custom 
specs file in a non standard directory" and not bothered to read and 
*understand* the code
you are dealing with (ie: the real documentation) and not once come up 
with *any* "fix".

Then through selective quotes from the written documentation (which has 
not kept up with the code and is in several places quite frankly wrong) 
with misplaced emphasis attempt to disingenuously silence and/or 
bamboozle your critics/audience without any substantive *technical* 
arguments.

You even blustered through the *--prefix is king* argument when you 
require your own hack to gcc.c itself to actually make --prefix do what 
you assumed it was doing.
(I must say a far more heinous hack than anything I have done.
I adjust macros (thats what they are there for or they wouldn't be 
macros, they would be hard coded strings).
you blindly hacked a needless patch adding unneeded functionality 
upstream explicitly removed).

You have had 4 years of clfs to look at and yet did not in that time 
manage to understand anything enough to come up with the obvious 
response considering all the FUD you espoused, or even a reasonably 
working toolchain for yourself.

Why the hell should anyone take any credence in what *your opinion* is 
of how the toolchain is supposed to work when you can't fix your own 
perceived problems, produce horrible unneeded fixes for functionality 
which the code already provides (if you read and understand it)...
and then we look over to the abortion you use for your initial 
cross-toolchain.
*That* is setting a bad example.

If you are going to use a full on old-school cross-compiler, at least do 
THAT properly...
Hell at the very least use some symlinks such as

$prefix/$target_triple/sys-include -> /tools/include
$prefix/$target_triple/lib -> /tools/lib
$prefix/$target_triple/lib64 -> /tools/lib64

so the damn thing uses the intended search paths and can at least 
produce an executable and find its libraries and includes.
(you will have to excise some -B from the gcc build itself though for 
that to work multilib... see clfs 1.0 for the sed)


Now note the above.
Technical rebuttal, with a side order of derision.

No FUD as such. I dont need it.

>> See clfs sysroot for a 1 pass build. If you want one for native builds,
>> can post it.
>>     
>
> I've already said the CLFS Sysroot build is closest in spirit to how
> sysroot is meant to work. But
>
>  1) it's cross compilation and therefore useless as a mainstream build
>  2) it fails ICA verification dismally
>
>   
What is this "mainstream build" of which you speak. Do you take your 
audience for idiots. I thought we were here to teach them something.

So you in one breath deride the "proper Greg endorsed" method of using 
sysroot (which it appears you have never used in anger), then bitch 
about the
proposed LFS use of sysroot.

And you are then saying you are going to try with a NATIVE sysroot build.

/me gazes into his crystal ball
/me sees glibc symbol and version mismatch errors in your future

Think AC_RUN checks, locale generation (if you don't set  BUILD_CC in 
the glibc build to the hosts compiler... hell you'll need the patch 
anyway)... basically anything that is compiled as part of a package 
build which is used for generating/building components of the package.

The packages you are building dont know of sysroot, all they know is 
that they are being built native.

Glibc is backward compatible... your hosts glibc may or may not be 
forward compatible to the version you are building, hence may be quite 
unhappy when it has to run a binary compiled and linked against a newer 
version of glibc.

Should be a fun challenge for you, try it from an lfs6 era host (or even 
better RH6.2)...
You'll probably have to use all the techniques from cross-lfs sysroot 
but with additional hacks, and then use a /host-tools directory (you 
know, that horrible clfs hack /cross-tools) to compile current versions 
of all the packages you are migrating to for the host into.

You may as well just use a cross-toolchain...

[R]