On Wed, 2005-12-14 at 14:35 -0600, Mikey wrote:
> Well, I will have to argue with you on this point.  It is important to me 
> that the toolchain is compiled against itself.  Catching weird toolchain 
> errors on down the road in a production environment is not my idea of fun.  
> I suppose I will repeat the use of the word anal again...

That is what the later stages are there for, to recompile the toolchain.
Argue all you want, this is fact.

> > You cannot set USE flags for your lower stages.  You will need to create
> > a profile.  The USE flags *must* match what is in the profile.
> 
> Lower stages being 1-3?  During which stage are USE flags intended to be 
> used with catalyst?

Correct.  Only stage4 is safe for changing USE flags.

> > Well, stage2/use is invalid and ignored.  Also, stage3/use is invalid
> > and ignored.  You do not change the USE in stages 1 through 3.  Period.
> > To make changes to these stages, you need to make a new profile with
> > your changes.  This could either be done via editing your portage tree
> > before making the snapshot, or as portdir_overlay in each spec file.  No
> > hand-editing is ever required.
> 
> What about stage4?  If I want to build snapshots with nptl, userlocales, and 
> -nls, for example, I have to use a stage4?

No, you do what I said and make a profile.  I am honestly getting a
little frustrated with having to repeat this.  With a proper profile,
you can have a stage2/stage3 with nptl.  It isn't possible to have a
stage1 with nptl on x86, since nptl isn't ported to i386 CHOST.  Look at
default-linux/x86/dev/2006.0 as a good example, as we're using nptl by
default there.

> On the bug I submitted yesterday.  I just completed a stage1 -> stage2 -> 
> stage3 -> stage1 cycle, using no environment script, no USE flags, no 
> optimizations, the same thing happens.  It attempts to emerge glibc before 
> linux-headers, glibc looks for the headers in stage1root, they don't exist, 
> so it bombs....

I have no way of guaranteeing that the stages you made are good.  Please
follow the instructions I sent in my last email for your builds, as
there is no way for me to verify anything other than the recommended
procedures.  Use a known good stage3 tarball as a stage1 seed.  At that
point, you don't need to rebuild stage1.  Basically, to duplicate what
you have done you would need: stage3 -> stage1 -> stage2 -> stage3
(remember that the stage3 *must* be generic to build a stage1) ->
stage1.

Unfortunately, in many cases, catalyst is a "fix it yourself"
application.  If it doesn't break our release-building, it is reduced in
priority, as catalyst is first and foremost our release-building tool.

Patches are always welcome, however.

-- 
Chris Gianelloni
Release Engineering - Strategic Lead
x86 Architecture Team
Games - Developer
Gentoo Linux