Greg Schafer wrote: > 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. > > see below >> 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. No, I solve problems for which you have not catered for yet. CLFS deals with building from non-linux hosts. /host-tools (or in my case my home directory) is where the native bash, gnu sed, awk, grep and possibly if the host doesn't have a gnu toolchain a native gcc and binutils would go.
It just so happens it is neater overrall (for previously mentioned resons) to do it this way > I keep it simple. > > See below >> 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. > Cool, so next upcoming DIY build will consist of LDFLAGS="-Wl,-dynamic-linker,/foo/bar/ld-linux.so.2 -Wl,-rpath-link,/foo/bar/lib" \ CPPFLAGS="-isystem /foo/bar/include" \ CFLAGS="-B/foo/bar/lib" There we go, no toolchain edits and using ONLY the specified *user* *interface*, it keeps things simple. You generate and hack a specs file providing the functionality your toolchain should have out of the box. Then use a command line switch which is intended to alter gcc's binary (-B) search path used to locate gcc's binaries (cc1, collect2 etc), gcc's startfiles (crtbegin.o crtend.o) as a library search path. What is more simple than specifying *NO ADDITIONAL* options to the compiler and *NO SPECS EDIT* to make the compiler function. >> 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. > > OK your unnecessary patch is newer than I thought. >> 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. > Heh, that is showing that the toolchain behaves EXACTLY as a native unmodified toolchain does. Isn't your supposed goal technical perfection that us mere LFS mortals can only aspire to? Apart from searching /tools it does exactly everything the gcc devs intended as a result of doing the job properly. > Again, you solve problems that don't exist. I keep it simple. > Lets see here DIY source hack **if [[ $BINUTILS_VER > 2.17.9 && $GCC_VER > 4.1.9 && $GLIBC_VER > 2.5.9 ]]; then** ** patch -p1 -i $TT_PFX/src/patches/gcc-4.2-branch-hash-style-gnu-2.patch** ** sed -i.bak '/^#define LINK_SPEC/s/i386} \\/i386} --hash-style=gnu \\/' \** ** gcc/config/i386/linux64.h** **fi** **sed -i.bak "s...@$dl@$TT_PFX&@" gcc/config/$DL_HEADER** **[ "$BIARCH" = YES ] &&** ** sed -i.bak2 "s...@$dl32@$TT_PFX&@" gcc/config/$DL_HEADER** **echo '** **/* Remove /usr/include from include search path. */** **#undef STANDARD_INCLUDE_DIR** **#define STANDARD_INCLUDE_DIR 0** **/* Remove /lib and /usr/lib from startfiles search path. */** **#define STANDARD_STARTFILE_PREFIX_1 ""** **#define STANDARD_STARTFILE_PREFIX_2 ""' >> gcc/config/$DL_HEADER** **sed -i.bak \** ** 's,\./fixinc\.sh,-c true,' gcc/Makefile.in** ** ** LFS source hack echo " #undef STANDARD_STARTFILE_PREFIX_1 #undef STANDARD_STARTFILE_PREFIX_2 #define STANDARD_STARTFILE_PREFIX_1 \"/tools/lib/\" #define STANDARD_STARTFILE_PREFIX_2 \"\"" >> gcc/config/linux.h cp -v gcc/Makefile.in{,.orig} sed -e "s...@\(^NATIVE_SYSTEM_HEADER_DIR =\)....@\1 /tools/incl...@g" \ gcc/Makefile.in.orig > gcc/Makefile.in # And to be anally retentive, nuke any mention of /usr/include # out of cppdefault.c cp -v gcc/cppdefault.c{,.orig} sed -e '/#define STANDARD_INCLUDE_DIR/s@"/usr/include"@0...@g' \ gcc/cppdefault.c.orig > gcc/cppdefault.c WTF are you talking about, looks like theres a fair amount of "hacking the source" in your build.. Who are you trying to kid, or do you think everyone here is stupid.. BTW heres an alternative gcc mod which does not obfuscate what is being done with the toolchain (tested from a solaris to linux cross-lfs build prior to new years, full logs upon request) 1) specify --without-local-prefix during gcc configure ie: stop using LOCAL_INCLUDE_DIR for finding our includes 2) perform only the following edits echo " #undef STANDARD_INCLUDE_DIR #undef STANDARD_STARTFILE_PREFIX_1 #undef STANDARD_STARTFILE_PREFIX_2 #define STANDARD_INCLUDE_DIR \"/tools/include\" #define STANDARD_STARTFILE_PREFIX_1 \"/tools/lib/\" #define STANDARD_STARTFILE_PREFIX_2 \"\"" >> gcc/config/linux.h cp -v gcc/Makefile.in{,.orig} sed -e "s...@\(^NATIVE_SYSTEM_HEADER_DIR =\)....@\1 /tools/incl...@g" \ gcc/Makefile.in.orig > gcc/Makefile.in Apart from the dynamic linker mods, everything we are doing to the toolchain is documented right there in a way "mere mortals" can understand without obfuscation. (well, apart from the makefile mods which ensure gcc finds limits.h in the correct location and ensures the fixincludes process (if you choose to run it) doesn't look outside of /tools) >> 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 > > So its taken 10 months and yet no-one has bothered to add a simple string check on the last 5 characters of the value passed to -B to see if it ends with /lib/ . It would take 5 minutes to generate a simple patch to do this (even by us LFS nut hugging morons), submit one. You can code right? Would you like me to do it for you. >> 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. > > I'll change the analogy: I fly in first class without having to lift a finger on my comfortable ride to the destination You are in economy trying to hold your seat together >> 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. > > Present build ensures our toolchain works by itself. DIY toolchain without command line switches and generating and sed'ing specs cannot find includes, libraries or produce a binary Take your pick. Congrats, there is nearly a valid argument in there this time. Best Regards [R] -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
