Adapting LFS SVN for multilib
gschafer at zip.com.au
Wed Jan 14 12:40:23 PST 2009
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.
"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
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
> 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.
More information about the lfs-dev