Greg Schafer wrote: > The facts are, our current native build method relies on the ability to > link against the host libc with the target ld. There is nothing inherently > wrong with this approach because it should always work in typical LFS > build scenarios (barring bugs of course). Yes, it would probably be better > if we could avoid it somehow, but the build method would need to change > radically in order to achieve this - cross compilation, gross hacks, > whatever.
Hmmm, thinking about this some more, there might actually be another option and that's the one already raised by Alex ie: don't bootstrap GCC pass1 (possibly move the bootstrap to pass2 as suggested by Jeremy). As it currently stands, the new tools start being used in combo with the host glibc during stage2 of the bootstrap. We could avoid this by dropping the bootstrap of pass1. That leaves the only exposed areas as kernel headers installation and glibc configure, but if they cause problems, we might be able to get away some PATH twiddling. There might be some merit here.. I'll chew on it for a while and maybe try some tests. 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
