Greg Schafer wrote: > The thread starts here and is quite interesting and features input > from the usual toolchain gurus: > > http://sourceware.org/ml/binutils/2007-08/msg00198.html >
Indeed. However, as you point out, it is not explained why the problem is specific to x86_64 (and a proposed two-line patch changes architecture-independent code). So I am afraid that a bug still exists somewhere and will manifest itself again (and again, only on x86_64) when someone adds a new DT_* dynamic section tag that is supposed to be backwards compatible. If you agree with this opinion, I think it would be a good idea express it upstream in that thread. > In summary, it basically confirms everything we already knew and also what > I've been saying all along here on lfs-dev. ie: > > - it's an x86_64 binutils-2.17 bug > - binutils devs are reluctant to fix bugs in old releases > - hash-style is supposed to be back-compatible > - a 2 line patch works around the problem > Yes, I think this is good enough for now for the DIY reference build, if it is clearly stated that the patch is a workaround. Not sure about LFS - the x86 build is not affected, the x86_64 branch apparently (Jeremy: am I right?) should not be used (because it is merged into jh), and the jh branch solved the problem by upgrading binutils. > 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. If someone can come up with something sane (and tasteful!) that > works, great, let's look at it. But I'm not holding my breath.. > I will try to cross-compile the least possible set of packages on x86 and x86_64, just to see where one can stop the gross hacks. > At the risk of dredging up old flamewars, I'd be very reluctant myself to > involve cross compilation in a mainstream build method. It's all been said > before, but I'll repeat just this point - IMHO cross compilation is a > specialty niche area that is not at all well suited to the relatively > simple task of building a new Linux system for Joe Sixpack (typical LFS > audience). It *is* complicated and relatively few folks understand it. > All facts are above and in the binutils thread, so IMHO there is nothing to flame about. > And finally, Alex, you should be more careful with what you write. Making > wild and flagrant comments doesn't help anyone. You already have a > reputation for jumping to (sometimes wrong) conclusions so please just put > a little more thought into your postings. BTW, Alex, I would like to see > from you a clear set of guidelines listing all the possible bugs and > problems in the LFS LiveCD, even the ones you haven't discovered yet (just > joking! :-) An attempt (also to be taken as a joke) will be posted separately, because it is off-topic for this thread. There are indeed some unreported bugs, such as "ddccontrol does not support Intel 965G onboard graphics chipsets (patch available)". > See? Hopefully now you'll realise how ridiculous one of your > postings in this thread was. > Sorry. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
