Hi, On Thu, 8 Jun 2006 05:34:49 -0700 "Bob Young" <[EMAIL PROTECTED]> wrote:
> No, sorry that's just wrong. gcc is slotted, if the above were true > there would be no need for gcc-config in order to select a default > compiler. Did you follow the documentation pointer given in the mail you are replying to before making such statements? In fact, you're wrong here. > When a new compiler is emerged, it does *not* automatically > become the default system compiler, it must be selected, and that can > only happen after it has successfully been emerged. The first time a > new gcc compiler is emerged, it is indeed built with the previous > version of the compiler that is currently istalled as the system > default. You haven't understood a word from the posting you're replying to. > It does have to be emerged twice in order for it to be built with > itself, anybody who thinks otherwise doesn't understand the basic > principles of compiling and linking. Try to understand what you are replying to. GCC's internal build logic does the staging. That's got nothing to do with what your system calls when you issue "gcc", and only at that point the slotting of GCC versions comes into play. > > Because for basically every program on your system, they are > > *dynamically linked* against glibc. > > 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? What would that change? We're talking about GCC, not glibc. > > 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? If the build logic of those programs uses glibc statically, the specific ebuilds for such programs have to get updated in order to incorporate fixes that are needed in statically compiled libraries. Following *your* logic, one would have to do emerge -e world after the slightest update just for the case that the updated package is compiled statically into something. > The issue is about upgrading gcc and even the gcc upgrade howto > recommends an emerge -e world. It's clear that gcc it self at least > has to be emerged twice in order to build the new gcc *with* the new > gcc. Repeating this doesn't make it more true than being plain wrong. > > There is no value to having glibc or libstdc++-v3 in the first line. > > There is no value at all to doing that twice. > > Twice is the only way to build the new gcc *with* the new gcc. I > should have added the gcc-config select command in between, but I > thought that was pretty clearly necessary. He was talking about glibc at that point. I don't see no value either. > > 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 > > 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. Not sure here, but it may well be possible that the ebuild in question builds a gcc 3.3 for bootstrapping this, too. -hwh -- gentoo-user@gentoo.org mailing list
