| 1 |
> -----Original Message----- |
| 2 |
> From: richard.j.fish@×××××.com [mailto:richard.j.fish@×××××.com]On |
| 3 |
> Behalf Of Richard Fish |
| 4 |
> Sent: Wednesday, June 07, 2006 9:24 PM |
| 5 |
> To: gentoo-user@l.g.o |
| 6 |
> Subject: Re: [gentoo-user] gcc-4.1.1 |
| 7 |
> |
| 8 |
> |
| 9 |
> On 6/7/06, Bob Young <BYoung@××××××××××.com> wrote: |
| 10 |
> > chain. At the end of the first emerge -e system you may have a |
| 11 |
> new compiler, |
| 12 |
> > but that new compiler was built with the old compiler. |
| 13 |
> |
| 14 |
> This is false. Gcc uses itself to build itself. It uses the system |
| 15 |
> compiler to build an initial version of itself, and then uses that |
| 16 |
> version to build itself. And then for good measure, it uses that |
| 17 |
> version to build the final version. It's called a 3-stage bootstrap, |
| 18 |
> and is documented in the file INSTALL/build.html in the gcc sources. |
| 19 |
> You can also look at /usr/portage/eclass/toolchain.eclass to determine |
| 20 |
> that Gentoo uses the "bootstrap-lean" target by default. |
| 21 |
|
| 22 |
No, sorry that's just wrong. gcc is slotted, if the above were true there |
| 23 |
would be no need for gcc-config in order to select a default compiler. When |
| 24 |
a new compiler is emerged, it does *not* automatically become the default |
| 25 |
system compiler, it must be selected, and that can only happen after it has |
| 26 |
successfully been emerged. The first time a new gcc compiler is emerged, it |
| 27 |
is indeed built with the previous version of the compiler that is currently |
| 28 |
istalled as the system default. |
| 29 |
|
| 30 |
|
| 31 |
> Frankly, anybody who claims that gcc needs to be merged twice so it |
| 32 |
> can be built with itself and produce better object code does not have |
| 33 |
> a clue what they are talking about and you should simply disregard |
| 34 |
> anything else they have to say about what is necessary/useful when |
| 35 |
> upgrading gcc. |
| 36 |
|
| 37 |
It does have to be emerged twice in order for it to be built with itself, |
| 38 |
anybody who thinks otherwise doesn't understand the basic principles of |
| 39 |
compiling and linking. |
| 40 |
|
| 41 |
> > happen before glibc is rebuilt are linked against a glibc that was built |
| 42 |
> > with the old compiler. |
| 43 |
> |
| 44 |
> And guess what difference this makes to the end result. None. |
| 45 |
> Nada. Nothing. |
| 46 |
> |
| 47 |
> Because for basically every program on your system, they are |
| 48 |
> *dynamically linked* against glibc. |
| 49 |
|
| 50 |
Are you absolutely 100% sure that every single system utility and |
| 51 |
application is *dynamically* linked, and that no apps or utilities anywhere |
| 52 |
in the system specifies *static* linking? |
| 53 |
|
| 54 |
> There are a few statically linked programs that will include glibc |
| 55 |
> internally. These are used only for system recovery purposes...there |
| 56 |
> is no need to worry about them at all. |
| 57 |
|
| 58 |
Really, so people who intentionally and specifically want to upgrade |
| 59 |
absolutely *everything* should not worry about what gets left out because |
| 60 |
Richard says it's unimportant? |
| 61 |
|
| 62 |
The issue is about upgrading gcc and even the gcc upgrade howto recommends |
| 63 |
an emerge -e world. It's clear that gcc it self at least has to be emerged |
| 64 |
twice in order to build the new gcc *with* the new gcc. Whether this is |
| 65 |
strictly necessary or not is certaintly debatable, but since it executes |
| 66 |
fairly quickly, and seems a prudent step, I'd argue that it's a reasonable |
| 67 |
course. Of course a selecting the new gcc as the default with gcc-config is |
| 68 |
also required in between, but that's self evident. Adding gcc-config, glibc, |
| 69 |
binutils, libstdc++-v3, quickly covers the most important parts of the basic |
| 70 |
tool chain, and covers most utilities or apps that might specify static |
| 71 |
linking, and executes much much faster than an emerge -e system. |
| 72 |
|
| 73 |
> There is no value to having glibc or libstdc++-v3 in the first line. |
| 74 |
> There is no value at all to doing that twice. |
| 75 |
|
| 76 |
Twice is the only way to build the new gcc *with* the new gcc. I should have |
| 77 |
added the gcc-config select command in between, but I thought that was |
| 78 |
pretty clearly necessary. |
| 79 |
|
| 80 |
> Also, libstdc++-v3 is only needed by a few binary-only programs on |
| 81 |
> Gentoo. Moreover, it is simply a build of gcc-3.3.6, which as I |
| 82 |
> already said uses itself to build itself, so I cannot see any point in |
| 83 |
> ever re-merging libstdc++-v3 due to a gcc upgrade |
| 84 |
|
| 85 |
I know you said it, but that doesn't mean you were correct. The fact is that |
| 86 |
anything emerged is built with the currently selected system compiler, the |
| 87 |
first time a new compiler is emerged it is built with the current (old) |
| 88 |
compiler (duh). *After* it is successfuly emerged, it can be selected as the |
| 89 |
default system compiler, then re-emergeing gcc will result in the new |
| 90 |
compiler being built with the new compiler. |
| 91 |
|
| 92 |
The same holds true for libstdc++-v3 orginally it was built with the default |
| 93 |
system compiler, it makes sense to have it rebuilt with the new compiler. |
| 94 |
|
| 95 |
Regards, |
| 96 |
Bob Young |
| 97 |
|
| 98 |
|
| 99 |
-- |
| 100 |
gentoo-user@g.o mailing list |
Archives