On 6/7/06, Bob Young <[EMAIL PROTECTED]> wrote:
chain. At the end of the first emerge -e system you may have a new compiler, but that new compiler was built with the old compiler.
This is false. Gcc uses itself to build itself. It uses the system compiler to build an initial version of itself, and then uses that version to build itself. And then for good measure, it uses that version to build the final version. It's called a 3-stage bootstrap, and is documented in the file INSTALL/build.html in the gcc sources. You can also look at /usr/portage/eclass/toolchain.eclass to determine that Gentoo uses the "bootstrap-lean" target by default. Frankly, anybody who claims that gcc needs to be merged twice so it can be built with itself and produce better object code does not have a clue what they are talking about and you should simply disregard anything else they have to say about what is necessary/useful when upgrading gcc.
happen before glibc is rebuilt are linked against a glibc that was built with the old compiler.
And guess what difference this makes to the end result. None. Nada. Nothing. Because for basically every program on your system, they are *dynamically linked* against glibc. This means that you can recompile glibc with different CFLAGS, a different compiler version, whatever, and they will *never notice*. Well, unless you use broken CFLAGS or a broken compiler, but no amount of "emerge -e world" can help you then. There are a few statically linked programs that will include glibc internally. These are used only for system recovery purposes...there is no need to worry about them at all. Again, *anybody* who claims that the end result of a compile depends upon what version of glibc you have installed, much less what CFLAGS or compiler glibc was built with, does not know what they are talking about.
for most people. This page: http://forums.gentoo.org/viewtopic-t-345229.html is about doing an install, but it shows how to update a subset of the entire tool chain. Note that the article does in the end, do a double emerge -e system, so the the value of updating a toolchain subset is questionable for the article's purposes.
Any article, on the forums or anywhere else, that claims some speed benefit resulting from doing emerge -e world twice is wrong.
In short: emerge gcc-config glibc binutils libstdc++-v3 gcc emerge gcc-config glibc binutils libstdc++-v3 gcc emerge -e world
There is no value to having glibc or libstdc++-v3 in the first line. There is no value at all to doing that twice. Also, libstdc++-v3 is only needed by a few binary-only programs on Gentoo. Moreover, it is simply a build of gcc-3.3.6, which as I already said uses itself to build itself, so I cannot see any point in ever re-merging libstdc++-v3 due to a gcc upgrade, much less doing that 3 or 4 times!
To be clear, in order to make sure absolutely everything is updated and the libraries that are linked against are also updated prior to use, the two emerge -e system commands, are the definitive solution. For those who don't want to spend many extra hours of compile time, in order to gain a 0.5% increase in performance, the above is offered for consideration.
No, there will not even be a 0.5% increase in performance. Not even 0.1%. Not even 0.000000000.....000001%. -Richard -- gentoo-user@gentoo.org mailing list
