Greg Schafer wrote: > Jeremy Huntwork wrote: > >> 1. Move to DIY's new build method in trunk. If we ignore multilib and >> any extra arch support for this step, the changes required aren't >> actually that many, and they all take place pretty early in chapter 5. > > I realize you say "this step", but LFS is already too far behind, 64-bit > should be top priority.
Actually, as I'm looking at it now, at least in terms of handling the XML, I'm thinking that you're right, it's going to be easier to merge the 64-bit changes in first. The changes required to pull in your method aren't really that many, but they do change things around a bit. But I know that's not really your point. You're speaking more to the logical development of the features. We are actually trying to do a good deal of 'catching up' here. All at once we're aiming for 64-bit, a new build method that supports multilib, and PM. Well, all I can say is, prepare for trunk to experience some periods of brokenness in the near future as we bring all this in. I think I'm going to start by bringing in the work that has already been done, namely allowing for 64-bit or 32-bit native in one book. Udev changes can be dropped in anytime, so can the DESTDIR stuff, since that's all in chapter 6. Greg, as I have your attention, I'm curious why the -fomit-frame-pointer change is still present in your second pass of gcc. I thought the purpose of this was to maintain compatibility between the first bootstrapped pass of gcc and the second pass? -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
