Re: [gentoo-dev] Re: Re: Re: bootstrapping since gcc 3.4 is stable

[Mikey]

On Wednesday 25 January 2006 18:27, Chris Gianelloni wrote:

> You didn't follow the Handbook.  Your comments about compiling GCC 3
> times are completely unbased, since you ran not only an "emerge -e
> system" (which is recommended) but then immediately, and needlessly,
> followed it up with an "emerge -e world" which pretty much blew any
> results that you had gained out of the water.

No, I didn't follow the handbook because I knew a gcc migration was 
involved.  http://www.gentoo.org/doc/en/gcc-upgrading.xml, Code Listing 
3.6, suggests to emerge -e system emerge -e world as the "safe" route.

The goal was to get the current gentoo toolchain from the current portage 
snapshot and latest available stage3 tarball, using the stage3 installation 
method.  If I had followed the handbook, I would have ended up with gcc 
3.3.6 and gcc 3.4.4 installed, but everything built with 3.3.6.  So to be 
completely accurate, if I had gone by the handbook and not the gcc 
migration guide, the build times for the stage3 method would have taken 4x 
longer than a stage1 instead of 2x.

My entire point was the the mind blowing waste of time required to obtain a 
current gentoo install using the stage3 installation method.  Unbased?  I 
think not.

> There are no "facts" in what you posted.  In fact, it looks as if your
> designs were tailored to find a way in which you could get a stage3 to
> be slower.  If you're willing, I will work on the scripts to produce
> *accurate* results for stages 1 and 3.  Essentially, your data was
> worthless since you didn't follow any prescribed way of using a stage3
> tarball, nor did you anywhere cite where you came up with your
> procedures.

I didn't tailor anything, I followed the exact same process anyone would 
need to follow to download a stage3, install the current portage snapshot, 
and get their system compiled with the default stable gcc (3.4.4).

> I just did.  You can stick with your "facts" all that you want, but
> they're incorrect.

> Here's a simple pseudo-formula to determine just how off you were:
>
> (Yes, this is simplified slightly)
>
> stage1 == tarball + toolchain (bootstrap) + system
> stage3 == tarball + system + depclean

Try it.  Take my script and make it closer to the reality you describe.  As 
long as the end result is the same - a system compiled against the current 
stable gcc, using the current snapshot.

Sure, at some point in the future the "current" official stages will contain 
the "current" toolchain, and building from a stage3 will be quicker, much 
quicker.  But gentoo is a moving target, it does not stay static.  The 
stage1 method produces consistent results and it does not really matter 
what USE flags you throw at it, it works without having to jump through 
undocumented hoops.  That is until someone throws in circular dependencies, 
which are fairly easy to work around.

> I'm sorry, but I cannot possibly believe that compiling the toolchain +
> the system target takes less time than only compiling system and
> summarily removing unused packages.  This, by the way, would have
> avoided the issues that you were having with things like "ls" being
> broken.

It takes less time because the first pass of the bootstrap is a bootstrap 
pass.  With a corrected bootstrap.sh, just using userlocales (something 
nearly impossible to do on the first pass with the currently broken 
bootstrap.sh) cuts the build time almost a forth.  The first gcc build does 
not build g++ either, further cutting out unneeded double building.  You 
also don't waste your time upgrading from gcc 3.3.5, to gcc 3.3.6, to 
3.4.4.  I didn't make that shit up.