Stephen P. Becker wrote: > Which is precisely your problem. You are blindly eating your food > without contemplating the contents.
Perhaps I am just contemplating a little deeper than you are. > >>> 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. Which happens to be the exact same method to get a stage3 upgraded also. Feel free to provide me with a link to better official documentation that covers it. > 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. I'm not talking about the past. I can't travel through time and determine what was and was not masked on your box. The test condition was to get the current stage3 installed with the current stable gcc, gcc-3.4.4 for x86. > 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. In which case you would not be running a box with the current toolchain and you would have to turn around and do it all over again later, therefore wasting 4x the amount of time to get your stage3 and/or running install upgraded. To further educate you, there was a bug shortly after the release of 3.4.4 into stable that did, in fact, automatically switch you over to the new gcc. It was in the toolchain eclass. > 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? The test, what I am debating about, and my primary assertion is that the stage3 installation method is not superior to the stage1/bootstrapping installation method. The official gcc migration instructions happen to be the same for both a stage3 install and a running installation. If you cannot grasp nuanced discussion, I can't help you learn anything new. > 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. No, they are not anywhere near the same. The end goal is the same, how effectively they get there and the predictability of reaching the desired goal is very different. If you find it a superior approach to go through 226 emerges instead of 99 over twice the amount of time to arrive at the same destination, more power to you and the misinformed people who listen to you. > My facts are already straight, and you are still an idiot. Whatever. -- gentoo-dev@gentoo.org mailing list
