Aiming for 7.0

[Jeremy Huntwork]

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