Others have already coverd the major points, so just a couple of things to add...
On 6/8/06, Bob Young <[EMAIL PROTECTED]> wrote:
Are you absolutely 100% sure that every single system utility and application is *dynamically* linked, and that no apps or utilities anywhere in the system specifies *static* linking?
I didn't say "every single system utility and application". I said "basically every program", which was a bad way of saying "almost all", since it might not be obvious for non-native english speakers (and even some native english speakers).
> 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. Really, so people who intentionally and specifically want to upgrade absolutely *everything* should not worry about what gets left out because Richard says it's unimportant?
No. They should follow the gcc upgrade guide that says emerge -e system followed by emerge -e world. BTW, I was incorrect when I stated "only for system recover purposes". The static programs do include things like busybox (which doesn't use glibc at all AFAIK), nash, and insmod.static, which are /mostly/ useful for system recovery. But it also includes things that have to run before the root filesystem is mounted, like splash and suspend utilities. I still think anybody worried about the performance of (e.g.) lvm is a bit crazy, but if they want to remerge it after remerging glibc to get the new "optimized" code, well, so be it...
The same holds true for libstdc++-v3 orginally it was built with the default system compiler, it makes sense to have it rebuilt with the new compiler.
There is simply no way to build libstdc++-v3 with the new compiler; it would break any programs that need it. Gcc likes to make incompatible changes in the C++ ABI from one version to the next, so building -v3 with the new gcc would give you the old stdc++ library, but the new ABI, and your programs would be broken. This is one of the major reasons that gcc uses itself to build itself, to make sure that it's ABI is consistent. -Richard -- gentoo-user@gentoo.org mailing list
