| 1 |
On 6/7/06, Bob Young <BYoung@××××××××××.com> wrote: |
| 2 |
> chain. At the end of the first emerge -e system you may have a new compiler, |
| 3 |
> but that new compiler was built with the old compiler. |
| 4 |
|
| 5 |
This is false. Gcc uses itself to build itself. It uses the system |
| 6 |
compiler to build an initial version of itself, and then uses that |
| 7 |
version to build itself. And then for good measure, it uses that |
| 8 |
version to build the final version. It's called a 3-stage bootstrap, |
| 9 |
and is documented in the file INSTALL/build.html in the gcc sources. |
| 10 |
You can also look at /usr/portage/eclass/toolchain.eclass to determine |
| 11 |
that Gentoo uses the "bootstrap-lean" target by default. |
| 12 |
|
| 13 |
Frankly, anybody who claims that gcc needs to be merged twice so it |
| 14 |
can be built with itself and produce better object code does not have |
| 15 |
a clue what they are talking about and you should simply disregard |
| 16 |
anything else they have to say about what is necessary/useful when |
| 17 |
upgrading gcc. |
| 18 |
|
| 19 |
> happen before glibc is rebuilt are linked against a glibc that was built |
| 20 |
> with the old compiler. |
| 21 |
|
| 22 |
And guess what difference this makes to the end result. None. Nada. Nothing. |
| 23 |
|
| 24 |
Because for basically every program on your system, they are |
| 25 |
*dynamically linked* against glibc. This means that you can recompile |
| 26 |
glibc with different CFLAGS, a different compiler version, whatever, |
| 27 |
and they will *never notice*. Well, unless you use broken CFLAGS or a |
| 28 |
broken compiler, but no amount of "emerge -e world" can help you then. |
| 29 |
|
| 30 |
There are a few statically linked programs that will include glibc |
| 31 |
internally. These are used only for system recovery purposes...there |
| 32 |
is no need to worry about them at all. |
| 33 |
|
| 34 |
Again, *anybody* who claims that the end result of a compile depends |
| 35 |
upon what version of glibc you have installed, much less what CFLAGS |
| 36 |
or compiler glibc was built with, does not know what they are talking |
| 37 |
about. |
| 38 |
|
| 39 |
> for most people. This page: http://forums.gentoo.org/viewtopic-t-345229.html |
| 40 |
> is about doing an install, but it shows how to update a subset of the entire |
| 41 |
> tool chain. Note that the article does in the end, do a double emerge -e |
| 42 |
> system, so the the value of updating a toolchain subset is questionable for |
| 43 |
> the article's purposes. |
| 44 |
|
| 45 |
Any article, on the forums or anywhere else, that claims some speed |
| 46 |
benefit resulting from doing emerge -e world twice is wrong. |
| 47 |
|
| 48 |
> |
| 49 |
> In short: |
| 50 |
> |
| 51 |
> emerge gcc-config glibc binutils libstdc++-v3 gcc |
| 52 |
> emerge gcc-config glibc binutils libstdc++-v3 gcc |
| 53 |
> emerge -e world |
| 54 |
|
| 55 |
There is no value to having glibc or libstdc++-v3 in the first line. |
| 56 |
There is no value at all to doing that twice. |
| 57 |
|
| 58 |
Also, libstdc++-v3 is only needed by a few binary-only programs on |
| 59 |
Gentoo. Moreover, it is simply a build of gcc-3.3.6, which as I |
| 60 |
already said uses itself to build itself, so I cannot see any point in |
| 61 |
ever re-merging libstdc++-v3 due to a gcc upgrade, much less doing |
| 62 |
that 3 or 4 times! |
| 63 |
|
| 64 |
> To be clear, in order to make sure absolutely everything is updated and the |
| 65 |
> libraries that are linked against are also updated prior to use, the two |
| 66 |
> emerge -e system commands, are the definitive solution. For those who don't |
| 67 |
> want to spend many extra hours of compile time, in order to gain a 0.5% |
| 68 |
> increase in performance, the above is offered for consideration. |
| 69 |
|
| 70 |
No, there will not even be a 0.5% increase in performance. Not even |
| 71 |
0.1%. Not even 0.000000000.....000001%. |
| 72 |
|
| 73 |
-Richard |
| 74 |
-- |
| 75 |
gentoo-user@g.o mailing list |
Archives