1 |
Hi, |
2 |
|
3 |
On Thu, 8 Jun 2006 05:34:49 -0700 "Bob Young" <BYoung@××××××××××.com> |
4 |
wrote: |
5 |
|
6 |
> No, sorry that's just wrong. gcc is slotted, if the above were true |
7 |
> there would be no need for gcc-config in order to select a default |
8 |
> compiler. |
9 |
|
10 |
Did you follow the documentation pointer given in the mail you are |
11 |
replying to before making such statements? In fact, you're wrong here. |
12 |
|
13 |
> When a new compiler is emerged, it does *not* automatically |
14 |
> become the default system compiler, it must be selected, and that can |
15 |
> only happen after it has successfully been emerged. The first time a |
16 |
> new gcc compiler is emerged, it is indeed built with the previous |
17 |
> version of the compiler that is currently istalled as the system |
18 |
> default. |
19 |
|
20 |
You haven't understood a word from the posting you're replying to. |
21 |
|
22 |
> It does have to be emerged twice in order for it to be built with |
23 |
> itself, anybody who thinks otherwise doesn't understand the basic |
24 |
> principles of compiling and linking. |
25 |
|
26 |
Try to understand what you are replying to. GCC's internal build logic |
27 |
does the staging. That's got nothing to do with what your system calls |
28 |
when you issue "gcc", and only at that point the slotting of GCC |
29 |
versions comes into play. |
30 |
|
31 |
> > Because for basically every program on your system, they are |
32 |
> > *dynamically linked* against glibc. |
33 |
> |
34 |
> Are you absolutely 100% sure that every single system utility and |
35 |
> application is *dynamically* linked, and that no apps or utilities |
36 |
> anywhere in the system specifies *static* linking? |
37 |
|
38 |
What would that change? We're talking about GCC, not glibc. |
39 |
|
40 |
> > There are a few statically linked programs that will include glibc |
41 |
> > internally. These are used only for system recovery |
42 |
> > purposes...there is no need to worry about them at all. |
43 |
> |
44 |
> Really, so people who intentionally and specifically want to upgrade |
45 |
> absolutely *everything* should not worry about what gets left out |
46 |
> because Richard says it's unimportant? |
47 |
|
48 |
If the build logic of those programs uses glibc statically, the |
49 |
specific ebuilds for such programs have to get updated in order to |
50 |
incorporate fixes that are needed in statically compiled libraries. |
51 |
|
52 |
Following *your* logic, one would have to do emerge -e world after the |
53 |
slightest update just for the case that the updated package is compiled |
54 |
statically into something. |
55 |
|
56 |
> The issue is about upgrading gcc and even the gcc upgrade howto |
57 |
> recommends an emerge -e world. It's clear that gcc it self at least |
58 |
> has to be emerged twice in order to build the new gcc *with* the new |
59 |
> gcc. |
60 |
|
61 |
Repeating this doesn't make it more true than being plain wrong. |
62 |
|
63 |
> > There is no value to having glibc or libstdc++-v3 in the first line. |
64 |
> > There is no value at all to doing that twice. |
65 |
> |
66 |
> Twice is the only way to build the new gcc *with* the new gcc. I |
67 |
> should have added the gcc-config select command in between, but I |
68 |
> thought that was pretty clearly necessary. |
69 |
|
70 |
He was talking about glibc at that point. I don't see no value either. |
71 |
|
72 |
> > Also, libstdc++-v3 is only needed by a few binary-only programs on |
73 |
> > Gentoo. Moreover, it is simply a build of gcc-3.3.6, which as I |
74 |
> > already said uses itself to build itself, so I cannot see any |
75 |
> > point in ever re-merging libstdc++-v3 due to a gcc upgrade |
76 |
> |
77 |
> The same holds true for libstdc++-v3 orginally it was built with the |
78 |
> default system compiler, it makes sense to have it rebuilt with the |
79 |
> new compiler. |
80 |
|
81 |
Not sure here, but it may well be possible that the ebuild in question |
82 |
builds a gcc 3.3 for bootstrapping this, too. |
83 |
|
84 |
-hwh |
85 |
-- |
86 |
gentoo-user@g.o mailing list |