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

["Stephen P. Becker" <geoman@gentoo.org>]

Mikey wrote:
> On Wednesday 25 January 2006 19:49, Stephen P. Becker wrote:
> 
>> You aren't serious, are you?  Did *you* read the fucking manual *and*
>> comprehend it?  Methinks not...upgrading from 3.3 to 3.4 in a
> 
> I didn't write the manual, so save your hubris for whoever did.  I just 
> followed its instructions, I ate the dog food.

Which is precisely your problem.  You are blindly eating your food 
without contemplating the contents.


>> pre-existing install != installing from a fresh stage.  First, running
>> bootstrap.sh with the new gcc version unmasked would completely get rid
>> of the "-e system" part of that howto, since that would force your
>> toolchain to rebuild itself.  Second, the -e world is to ensure that
>> your full install (which surely has plenty of c++ apps outside of
>> system) is linked against the libstdc++ of the new gcc.
> 
> The test has nothing to do with installing from a pre-existing install.

Exactly!  Yet, the gcc upgrading guide which you follow so blindly and 
religiously *is* meant for upgrading from a pre-existing install.


> The test was getting a current gentoo stage tarball with a current portage 
> snapshot up to date, stage1 -vs- stage3.  Nothing was unmasked either.  
> Were you are pulling that from is beyond me.

I was just noting that in the past, gcc 3.4 would have been masked for 
some people.  If you want s/3.3/3.4/, and s/3.4/4.0/ now, because it is 
the same situation.  However, it really doesn't matter here.


> Running an emerge -e system does not magically switch you over to the new 
> gcc, it would uselessly recompile the entire system with gcc 3.3.4 again.

This is extremely funny.  So, without even comprehending what you are 
typing, you just said (in a roundabout way) that if you did bootstrap.sh 
and then used gcc-config to set 3.4 as your system compiler, that your 
system compiler would *not* be switched over to 3.3 at any time during 
emerge -e system...and you are 100% correct!  Remember, gcc is slotted. 
  If you are really that paranoid, simply unmerge the 3.3.x gcc after 
you have run bootstrap.sh.


> Hence the need to READ AND COMPREHEND the instructions in the gcc migration 
> guide, which was plainly announced in GWN at the time.  If you don't 
> believe me, go troll around the forums a little and try to help the poor 
> saps who didn't realize they needed to follow that guide.  Even half of the 
> ones who did read the guide completely dorked up their running boxes.

Wow, you sure like to contradict yourself.  You keep jumping back and 
forth between talking about a new install and running installs.  Care to 
make your mind up at some point?


>> Remember, in a pristine stage3, system == world.  Therefore, your
>> "comparison" is really telling folks to emerge -e system twice in a row.
>>   Doing bootstrap.sh followed by 'emerge -e system' from a stage3 is the
>> same thing as doing bootstrap.sh followed by 'emerge -e system' from a
>> stage1...sorry to burst your bubble.  So again, idiocy and FUD.
> 
> If you actually downloaded a "pristine" stage1 or a stage3 tarball you might 
> notice that there are, in fact, packages already present in world.  Glibc, 
> gettext, nano, gzip, and linux-headers.

Of course there are, but they are also part of system.  Remember, a 
stage3 is equivalent to having run bootstrap.sh followed by emerge 
system from a stage1.  This is how it has *always* been.


>  Not that that matters one iota to 
> this conversation, but you need to get your own facts straight before 
> running around calling people idiots.

My facts are already straight, and you are still an idiot.


> The difference in doing from stage1 instead of stage3 is you don't have to 
> go through a gcc migration to prevent your build from being unusable.  You 
> also go through 1 gcc upgrade (gcc 3.3.5 -> gcc 3.4.4), not 3 (3.3.5 -> 
> 3.3.6 -> 3.4.4).  We are talking reality here, not fantasy.

Your reality is fantasy.


-Steve

-- 
gentoo-dev@gentoo.org mailing list