Greg Schafer wrote: > Jeremy Huntwork wrote: > > >> It >> is a new approach compared to earlier versions of LFS in that the the >> first pass of binutils and gcc we are creating cross compilers and the >> chapter 5 glibc is cross compiled. It is a native build from that point >> forward. >> >> Some weeks ago, Ryan proposed a somewhat alternative method >> > > Huh? Not quite. > > It's still the same basic method that *I* developed. Cross toolchain for > Pass 1, cross compile temp Glibc, native thereafter.
Look back into the clfs-lite that was proposed 4 years ago in the lfs wiki. Referenced here http://linuxfromscratch.org/pipermail/lfs-dev/2005-April/051171.html Wonder if we can still find it... > Please don't lose > sight of the fact that I developed the basic concept Heh. The ego knows no bounds. LFS style builds are a subset of what we have been doing for years. > *[1]. I did the > testing. I got it working. Ryan has introduced some "adjustments" to the > method. Some good, some not so good. > > The irony is, Ryan's appearance here and jumping on board of the basic > idea actually *vindicates* what I've been saying for years - that CLFS is > massive overkill for those wanting a 64-bit multiarch toolchain. 4 years ago your opinion was markedly different with regards to using cross-compilers for any part of the lfs toolchain. You entirely miss the point of cross-lfs From a same era posting http://linuxfromscratch.org/pipermail/lfs-dev/2005-April/051161.html > I > actually did something about it. Now folks are taking notice. Remember way > back when CLFS fanboys were promoting CLFS as the next best thing? Where > are they now? :-) > > Working on clfs, as some outspoken folks were constantly deriding cross-compilation techniques as not fit for a "mainstream build" and spreading baseless FUD. Hence why CLFS is over at CLFS. >> that does not require any adjustment of the toolchain in chapter 5 >> > > I think this is a regression, actually, at least from an educational POV. > > From a functional point of view and minimising the potential for error however... and we teach folks directly what we are doing, ie: 1) not obfuscating how we set header search paths (--with-local-prefix= doesn't really tell us much) or 2) obfuscating how library search paths are handled (gcc.c hack to reintroduce --prefix for specifying library search path doesn't teach anything) >> and does not >> depend on using -B/tools/lib/, by the cross compiler in order to get it >> to find the new startfiles. There is also a patch that DIY and current >> trunk uses for GCC pass 2 which reverts GCC to old functionality so that >> it will use prefix to find the startfiles. Ryan's approach also does not >> require the use of this patch. >> > > Agreed. Those are warts. I've fixed them in my dev build and you should > continue with your current Pass 2 toolchain. > > >> This method uses sysroot functionality in GCC and Binutils to help >> 'mask' off the host system further. >> > > Huh? No! It's quite the opposite! This clearly demonstrates you don't > understand the sysroot feature at all. I'm surprised that I have to > explain this to you in detail, but I will anyway. And also keep in mind > you are using the sysroot feature in pass 1 only. > > Look at the source of gcc.c. Grep for `add_sysrooted_prefix' and note that > every call (bar one *[2]) occurs within the the block: > > if (*cross_compile == '0' || target_system_root) > > ie: if native build or sysrooted build > *HEH* Man you cant even understand simple code... and here I am having technical arguments with you... Read it again.... slowly.... and remember your boolean algebra. Remember, for a sysrooted cross-compiler cross_compile == 1 AND target_system_root *IS* defined > In other words, by using the sysroot feature in pass 1, you're bringing in > all the *native* host dirs into the equation! Hence your hacking of > STANDARD_STARTFILE_PREFIX_{1,2} in pass 1. > > That is in fact by design of the gcc devs. You REALLY did not understand the code, or what the purpose of sysroot is, did you. The point of sysroot build is to ALLOW the use of the standard macros to define the library and include search paths (more below) > The *whole* point of me using a non-sysroot cross compiler is to avoid > searching the host *at all*. Correct. for old school cross-compilers by default you used to copy over all your target system libraries into $prefix/$target_triple/lib and all your target system includes into $prefix/$target_triple/sys-include ( it used to be back in the day just $prefix/$target_triple/include) With a sysroot build (as opposed to an old school non-sysrooted cross-compiler) for its intended use it expects you to copy a whole root filesystem from the target system (or NFS mount it) into the specified sysroot. *That* is the purpose of sysroot. It _NEEDS_ to search the specified native include and library search paths for it to work. > Not only that, by using the sysroot feature, > you fall afoul of the `inhibit_libc' configure logic. Therefore you're > forced to add even more configure switches > > --with-newlib > --without-headers > Or we could install the glibc headers prior to the gcc build (and when including the required pthread headers we also wouldn't have to --disable-thread.) You would however decry that as an "unnecessary" step. We are however building from scratch and have no libc headers, so have to force inhibit_libc first pass. > Not to mention how ridiculous `--with-newlib' is when you're not even > using newlib! Yet *another* blatant GCC docs violation! > > You love your docs... the source is the documentation... Would you prefer we just -Dinhibit_libc > The sole reason Ryan chooses to abuse the sysroot feature is because it's > the only way he can make multilib work (without using the already beaten > to death startfile_prefix_spec) ie: it allows him to (ab)use the *native* > STANDARD_STARTFILE_PREFIX_1 > > Your assumptions are FAIL due to your inability to even understand a simple boolean switch or the intended purpose of sysroot. Again, sysroot toolchain is SUPPOSED to use them. > In essence, what you gain on the swings, you lose on the roundabout. > > >> Greg says we're 'hacking the source' in the first pass of GCC, but if >> you actually look at the changes being done, it's the same modification >> of config/linux.h that the specs patch has always done >> > > You're making the changes in *both* passes. Unnecessary hackery and you > know it. Stop blurring the truth. > > In summary, the evidence against the use of sysroot in pass 1 is mounting. > You choose to ignore it, your problem. > > Regards > Greg > > *[1]. Alexander Patrakov deserves some credit for sparking the concept by > suggesting the possibility of: > > a) dropping the GCC bootstrap and > b) using a cross toolchain for Pass 1 > > *[2]. The other one is of course startfile_prefix_spec. But that's a whole > separate discussion, and one already beaten to death. > Thank you for providing all the ammunition I could possibly ever need. Now with the FUD completely out of the way and utterly discredited we can get back to discussion of what actually does happen in the real world. Best Regards [R] -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
