1 |
Stephen P. Becker wrote: |
2 |
|
3 |
> Which is precisely your problem. You are blindly eating your food |
4 |
> without contemplating the contents. |
5 |
|
6 |
Perhaps I am just contemplating a little deeper than you are. |
7 |
|
8 |
> |
9 |
>>> pre-existing install != installing from a fresh stage. First, running |
10 |
>>> bootstrap.sh with the new gcc version unmasked would completely get rid |
11 |
>>> of the "-e system" part of that howto, since that would force your |
12 |
>>> toolchain to rebuild itself. Second, the -e world is to ensure that |
13 |
>>> your full install (which surely has plenty of c++ apps outside of |
14 |
>>> system) is linked against the libstdc++ of the new gcc. |
15 |
>> |
16 |
>> The test has nothing to do with installing from a pre-existing install. |
17 |
> |
18 |
> Exactly! Yet, the gcc upgrading guide which you follow so blindly and |
19 |
> religiously *is* meant for upgrading from a pre-existing install. |
20 |
|
21 |
Which happens to be the exact same method to get a stage3 upgraded also. |
22 |
Feel free to provide me with a link to better official documentation that |
23 |
covers it. |
24 |
|
25 |
> I was just noting that in the past, gcc 3.4 would have been masked for |
26 |
> some people. If you want s/3.3/3.4/, and s/3.4/4.0/ now, because it is |
27 |
> the same situation. However, it really doesn't matter here. |
28 |
|
29 |
I'm not talking about the past. I can't travel through time and determine |
30 |
what was and was not masked on your box. The test condition was to get the |
31 |
current stage3 installed with the current stable gcc, gcc-3.4.4 for x86. |
32 |
|
33 |
> This is extremely funny. So, without even comprehending what you are |
34 |
> typing, you just said (in a roundabout way) that if you did bootstrap.sh |
35 |
> and then used gcc-config to set 3.4 as your system compiler, that your |
36 |
> system compiler would *not* be switched over to 3.3 at any time during |
37 |
> emerge -e system...and you are 100% correct! Remember, gcc is slotted. |
38 |
> If you are really that paranoid, simply unmerge the 3.3.x gcc after |
39 |
> you have run bootstrap.sh. |
40 |
|
41 |
In which case you would not be running a box with the current toolchain and |
42 |
you would have to turn around and do it all over again later, therefore |
43 |
wasting 4x the amount of time to get your stage3 and/or running install |
44 |
upgraded. To further educate you, there was a bug shortly after the |
45 |
release of 3.4.4 into stable that did, in fact, automatically switch you |
46 |
over to the new gcc. It was in the toolchain eclass. |
47 |
|
48 |
> Wow, you sure like to contradict yourself. You keep jumping back and |
49 |
> forth between talking about a new install and running installs. Care to |
50 |
> make your mind up at some point? |
51 |
|
52 |
The test, what I am debating about, and my primary assertion is that the |
53 |
stage3 installation method is not superior to the stage1/bootstrapping |
54 |
installation method. The official gcc migration instructions happen to be |
55 |
the same for both a stage3 install and a running installation. If you |
56 |
cannot grasp nuanced discussion, I can't help you learn anything new. |
57 |
|
58 |
> Of course there are, but they are also part of system. Remember, a |
59 |
> stage3 is equivalent to having run bootstrap.sh followed by emerge |
60 |
> system from a stage1. This is how it has *always* been. |
61 |
|
62 |
No, they are not anywhere near the same. The end goal is the same, how |
63 |
effectively they get there and the predictability of reaching the desired |
64 |
goal is very different. If you find it a superior approach to go through |
65 |
226 emerges instead of 99 over twice the amount of time to arrive at the |
66 |
same destination, more power to you and the misinformed people who listen |
67 |
to you. |
68 |
|
69 |
> My facts are already straight, and you are still an idiot. |
70 |
|
71 |
Whatever. |
72 |
|
73 |
-- |
74 |
gentoo-dev@g.o mailing list |