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. Please don't lose
sight of the fact that I developed the basic concept *[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. 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? :-)
> 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.
> 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
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.
The *whole* point of me using a non-sysroot cross compiler is to avoid
searching the host *at all*. 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
Not to mention how ridiculous `--with-newlib' is when you're not even
using newlib! Yet *another* blatant GCC docs violation!
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
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.
--
http://www.diy-linux.org/
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
