Adapting LFS SVN for multilib

[Greg Schafer]

Ryan Oliver wrote:

> Except you then are placing tools compiled and linked against the host 
> in the directory that is supposed to be clean.

Huh? I'm grouping *temporary* tools together in the one dir. It's not the
dir that's supposed to be clean. It's the build method.

You unnecessarily complicate the build. I keep it simple.

> 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.

All completely irrelevant in a mainstream build method. And like I said,
current DIY/LFS doesn't overwrite anything and is therefore restartable.

You solve problems that don't exist. I keep it simple.

> 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 makefile.in for that to happen without resorting to a specs edit), or 
> locates libraries or startfiles (which you misuse -B for).

Huh? I don't have to set anything. I follow the *man page* and use the
convenient command line switches provided *exactly* for includes, startup
files and libs. The more you say I misuse -B, the sillier you look.
>From   http://gcc.gnu.org/onlinedocs/gccint/Driver.html#Driver

"Here is the order of prefixes tried for startfiles:
  1. Any prefixes specified by the user with `-B'.
  2. <snip> etc, etc."

You hack the source. I keep things simple by using the provided *user*
*interface* wherever possible.

> 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).

Wrong. The patch is from GCC-4.2. Please get your facts straight.

> 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),

Honestly, nobody here gives a rats arse about relocating a toolchain. We
don't do it. We never relocate anything. These completely irrelevant
tangents you keep flying off on are astonishing.

Again, you solve problems that don't exist. I keep it simple.

> 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 

No one's disputing how -rpath-link works. It's just unnecessary, ugly and
error prone. Just look at the current CLFS mess.

You uglify your build unnecessarily. I keep things simple.

> 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..

Again, no disputing how LIBRARY_PATH works. Again, toolchain altering env
vars are error prone, fragile, and not suitable for mainstream. You said
it yourself years ago.

> 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 
> aware.

Welcome to 10 months ago! It happened while you were MIA. Read the GCC
thread and especially this post (from someone who actually knows what he's
talking about):

http://gcc.gnu.org/ml/gcc/2008-03/msg00767.html

> 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..

Educational? I hope you're joking. Folks want a simple build that does the
job and is easy to understand. Complicating the build unnecessarily is
just silly. An analogy is in order:

We both want to get from London to Paris.
We both get there in the end.
You make life hard for yourself by going via New York.
I fly directly over the channel.

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

Sysroot build for LFS-style build method is needless complication. Just
look at how many extra build commands you need. That's a fact.

Regards
Greg
-- 
http://www.diy-linux.org/