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/ -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
