Greg Schafer wrote:
Matthew Burgess wrote:
Trying to build using gcc-4.x would fail because glibc-2.3.5 installed
headers that had syntax errors that the new compiler complained about.
Umm, not exactly. It was Glibc-2.3.4. The issue you refer to is
now fixed in GCC (and Glibc) and is documented here:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20166
Thanks for the reminder of the bug I knew I had to workaround during
early gcc-4.x testing. Unfortunately, I forgot to keep track of the
upstream status of this in both glibc and gcc, hence my workaround never
got removed once it became unnecessary.
We obviously can't trust the host during early chapter 5, because it
could contain anything.
Correct. Fixincludes is mandatory for GCC-Pass1.. or else build failures
will occur on many hosts. This has been true for a very long time.
OK, at least I got one bit right :)
I therefore adopted the approach of letting fixincludes do its thing
(after all, it will know far better than we do
what needs fixing and what doesn't).
I strongly disagree with the above assertion. We've been through this many
times in the past. Fixincludes uses heuristics to determine what needs
fixing and therefore it can never be 100% accurate. The whole premise of
fixincludes is to allow GCC to bootstrap on systems with broken system
headers. Therefore, in the context of building a new system from scratch
(with up-to-date sources theoretically containing no broken headers), the
fixincludes process should not be required during GCC-pass2 and Ch6 GCC.
And now that you've hit me with the cluebat and pointed out that we no
longer have any known broken headers, then I completely agree with the
above.
If fixincludes is allowed to run during GCC-pass2 and Ch6 GCC and it does
indeed try to fix some headers, IMHO it is a bug in:
1) the package supplying those headers
or
2) the fixincludes component of GCC
Agreed. However, I'd prefer not to patch gcc if at all possible.
Therefore, the approach I'm going to take is:
1) Keep gcc-pass1 thru adjusting the toolchain the same. I think the
explanation of why we delete the fixincluded headers when we do in 5.7
could be improved though - I managed to confuse myself when I stumbled
across it again just now.
2) In gcc-pass2 and ch6-gcc, we allow the fixincludes process to run.
If it fixes anything we can: i) patch the offending package (if it
really is broken); ii) reintroduce the fixincludes-suppressing patch or
iii) Repeat the "delete the fixincluded headers" commands that we have
in 5.7.
Obviously i) is unneccesary at present, as we're not aware of any broken
headers. I prefer iii) over ii) simply because it means we have one
less patch to maintain across gcc upgrades (as trivial though such
maintenance may be).
Regards,
Matt.
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
