Jeremy Huntwork wrote: > Without using 'CC="gcc -B/usr/bin/"' the build fails with the same > error, but at stage2 instead of stage3. So the key seems to be that GCC > can be built correctly using the host's tools, but cannot be built > correctly using our new binutils.
This actually feels like it makes sense. And it seems to explain why saving bootstrapping for pass2 could be more robust. Instead of trying to bootstrap GCC using two possibly incompatible versions of binutils (using /usr/bin/ in stage1 and /tools/bin for stage2) we wait until we have a usable libc. Binutils and GCC pass1 are built using _only_ the host's gcc and binutils. Barring an utterly broken host, this should always produce usable tools for building libc as they are built entirely by the host's tools, and therefore both compatible with the host's environment. Next, we build Glibc. At this time we should now have a known set of tools, solid enough to bootstrap GCC, each stage using the same set of binutils, and everything linking against our new libc. (Of course, to verify a decent enough libc, we can run the testsuite according to the method Greg discovered.) Does that not sound right? -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
