On Tue, 2006-02-07 at 15:41 +1100, Greg Schafer wrote: > Jeremy Huntwork wrote: > > > In talking with Ryan Oliver, there seems to be one final thing that we > > can do to our current build which will help stabilize it completely: add > > 'make bootstrap' to the gcc build of chapter 6. > > Hmmmmm, this means you effectively end up building GCC 7 times, 3 times in > GCC-Pass1, 1 time in GCC-Pass2 and 3 times Ch6 GCC. Yup
> It also means you end > up with a final Glibc that was compiled by a non-bootstrapped GCC. Which isn't an issue, pass2 gcc is built with the bootstrapped gcc pass1 and will be searching the same locations for libs and headers that gcc pass1 did. > Are you > now going to bootstrap GCC-Pass2 as well? ie: effectively build GCC 9 > times? Nope, no need. > Or are you going to rebuild Glibc again at the end of Ch 6 as used > to happen many moons ago? Nope, not required. Ch6 glibc is built properly as it is > Starting to see some chicken and egg themes > here? (BTW, those questions were hypothetical so no need to answer them :-) > Oops, already did > IMHO, your proposal smacks of inefficiency. Using this enormous > sledgehammer approach is very much a cop-out when the problem is > relatively minor and can easily be solved using some good'ol toolchain > know how. Hacks? Possibly. Shortcuts breed workarounds and hacks, which look good at the time but introduce headaches or unintended consequences later. Sometimes we can be a little too clever for our own good trying to save a few cycles. > But we all know the whole 2 phase build method > approach is a huge hack anyway, and consequently, little hacks here and > there are inevitable. Yup, but preferably not for the final native gcc. There are no unintended consequences from using make bootstrap ch6, this cannot be said of other methods. > > This paragraph from an earlier post of mine[1] is also relevant: > > "One obvious way to address the issue would be to run `make bootstrap' for > each pass. But this is effectively building GCC 9 times. Not only is this > unnecessary and ridiculously time consuming (GCC4 bootstraps are MUCH > slower than GCC-3.x), it demonstrates a lack of understanding of the GCC > build process." > In summary, I don't agree. The LFS build is already slow as molasses and > now you want to make it even slower. Yup. Do folks want "fast" or do folks want "properly built". > No offence to Ryan's very good > technical skills, but already on numerous occasions his sledgehammer > techniques have been proven without a doubt to be genuine overkill. In this case I prefer the "works every time regardless" argument, saves on support issues when folks screw up whatever clever hack du jour is introduced, and it is one (several) less thing(s) to worry about in terms of maintenance. Best Regards Ryan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page