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 > 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. > Once glibc has been installed, with all its > associated headers (and the ones from the earlier gcc pass), we know > exactly what state the environment will be in. Therefore, we used to > prevent the fixincludes process from running, but as we've just > installed known broken headers again this will stop anything that > includes it (I think it was "pthread.h") from compiling. Erm, Glibc does not install "known broken headers" as of Glibc-2.3.5. > 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. The reason we first started disabling fixincludes during GCC-pass2 and Ch6 GCC was because an old GCC version we were using at the time actually broke the build because one of the "fixes" was faulty. Investigation then revealed that a lot of the other so called "fixes" were clearly unnecessary. Some of those old fixes have since been adjusted in the GCC (fixincludes) sources and headers that used to get "fixed" no longer get fixed with recent GCC's. 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 But any such fixes are clearly not needed anyway. The build is still pure without them, trust me :-) While ever the current build method is in use, it is my firm belief that the more robust and long-term solution is to disable fixincludes during GCC-pass2 and Ch6 GCC. > simply because I'm fairly confident that fixincludes knows better than > most of us on this list what may need fixing. As outlined above I beg to differ. Regards Greg -- http://www.diy-linux.org/ -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
