Randy McMurchy wrote:
> That said, I have always respected your ideas, though often I've
> thought your delivery was less-than-stellar.
Like it or lump it :-)
> You made a recent post
> which said that Jim's latest mass-change had some technical issues,
> but you didn't discuss the reasons why you thought that.
>
> I feel if you're going to say that someone's commit was less then
> beneficial to the project you should also explain why.
Of course.
> BTW - I am speaking about the comments you directed towards this
> change:
>
> * It removes glibc-headers from all architectures except for x86 and
> x86_64.
Yes, this "Glibc Headers" issue has been dealt with in detail in a DIY
mailing list posting. I'll reproduce the relevant excerpt below. But in
essence, I believe it's simply bad engineering to have different build
steps that are dependent on which arch you happen to be building. If
you're going to develop a technically correct and robust build method, it
should be identical across all architectures IMHO. Read below for some
technicalities.
Regards
Greg
Glibc Headers
-------------
The Glibc headers step is a particularly ugly step because the host GCC must
be used to run the Glibc configure script. It also relies on Glibc's
`install-headers' Makefile target which is fragile at best. Getting rid of
the need for this step would be a big improvement in the overall task of
producing a cross toolchain IMHO.
There has been debate in the past as to whether the Glibc headers step is
actually needed at all. Opinions have differed even within the GCC developer
community. I have done some testing and can confirm that Glibc based cross
toolchains for every target (with the exception of IA64) can indeed be built
without the Glibc headers step. Whether this is a wise thing to do or not is
another matter. See below..
Essentially, the crux of the issue revolves around `inhibit_libc', which is
defined by the GCC configure script in this snippet:
inhibit_libc=
if { { test x$host != x$target && test "x$with_sysroot" = x ; } ||
test x$with_newlib = xyes ; } &&
{ test "x$with_headers" = x || test "x$with_headers" = xno ; } ; then
inhibit_libc=-Dinhibit_libc
fi
It should be clear after studying the above as to when -Dinhibit_libc gets
defined. Consider that `--with-headers' is deprecated and we are not
building with newlib.. so from my POV, it all boils down to whether
`--with-sysroot' is passed or not. In other words, for a modern cross
compiler, if `--with-sysroot' is omitted the GCC build system will define
`inhibit_libc' which theoretically prevents the build from needing access to
Glibc headers.. which sounds like exactly what we want for the first
"bootstrap" or "pass1" cross compiler, right?. Unfortunately, `inhibit_libc'
doesn't protect every single instance of Glibc header inclusion.. but these
can easily be patched.. except for IA64 which just wants to be difficult :-)
Incidentally, here is yet another flaw in the Cross-lfs docs.. a cross GCC
is built 3 times to arrive at the final cross compiler. Each one of those
cross GCC's has `inhibit_libc' defined. Check your build logs if you don't
believe me. Why go to the trouble of installing the Glibc headers if you're
going to mostly elide them? It's just wrong.
These targets can be built "out of the box" without Glibc headers:
powerpc s390 sparc mips arm m68k
powerpc64 s390x sparc64 mips64 x86_64
These targets can be built without Glibc headers after minimal patching:
i686 sh3 sh4 alpha
This target cannot be built without Glibc headers (at least I couldn't make
it work even after applying serious surgery):
ia64
There are some obvious questions raised by the above. Do you end up with a
different compiler (binary comparison wise) depending on whether you
performed the Glibc headers step or not? The answer is yes, but only subtly
different and not in a harmful way AFAICT. Do you end up with a different
Glibc (binary comparison wise) depending on whether you built it with a GCC
built WITHOUT access to Glibc headers or with a GCC built WITH access to
Glibc headers? Again, the answer is yes. And again, only subtly and not in a
harmful way AFAICT.
The proof of the pudding is in the eating.. and to this end I was able to
run the Glibc/NPTL testsuite under i686 compiled with a cross toolchain
(using the faked host technique) by following the procedures outlined by me
in an earlier post (with the only addition needed being `cross-compiling=no'
added to the invocation) and the testsuite passed in both scenarios. This
tells me that it IS possible to build a fully functional cross toolchain
without access to Glibc headers.
But is it wise? Probably not. IA64 will not build without the headers and
some GCC heavyweights swear blind that you must provide them. There is some
deep voodoo related to Exception Handling and subtle GCC/Glibc interaction
involved here. Until I get further technical evidence, my gut instincts have
overridden my desire to get rid of the Glibc headers step. My procedures and
scripts will therefore default to building with the headers for the time
being, but the option is there to build without them if needed. I'll post
some more observations about this headers stuff later.
--
http://www.diy-linux.org/
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
