"Mark Haney" <[email protected]> posted [email protected], excerpted below, on Thu, 22 Jan 2009 09:54:01 -0500:
> One more thing, when I looked at gcc versions available on my system > 4.1.2 is the latest stable one. I take it that 4.3.2 is in ~amd64? Yes. One nice thing about Gentoo is that the way it uses gcc-config, you can have several gcc versions merged and switch between them. With the exception of C++ programs using libstdc++, there's very little reason to worry about switching between versions causing problems, and it's very convenient to have multiple versions available to test with, if a compile is breaking with one. As for libstdc++, in the bad old days (early gcc 3, I think, it was really before I got into compiling stuff much and possibly before I got into Linux much at all), different minor gcc versions sometimes had dramatic libstdc++ incompatibilities, but for quite some time it has been generally backward compatible and with only a few exceptions, usually forward compatible as well. The one set of exceptions I am aware of was that earlier KDE 3 used a few of the (then) newer libstdc++ functions from I believe it was gcc 4.0 or 4.1 if they were available at compile time, and that specific bit of kde (generally Internet related, local stuff seemed to work fine) would fail to work if compiled with the newer version then set to run against (due to gcc-config-ing back to) the older gcc/libstdc++. However, that only happened if it was compiled against the newer libstdc++ version then was run against the older one. If one compiled with the older version, it ran just fine against the newer version. And I was able to work with it just fine compiled against the newer version even when gcc-config-ed to an older version -- I just didn't use the broken bits, all Internet related, while pointing at the old version, and gcc-config-ed back to the newer version as soon as possible. IOW, I just had gcc-config pointing at the old version long enough to compile whatever it was that was still giving me trouble in the new version, then switched back to the new version, which I was using for normal system operations. So in general you should be pretty safe installing multiple gcc versions, then using gcc-config to temporarily point at whatever one you want to try. Just keep track of which one you're pointed at, and try to keep as much of the system as possible compiled with a single version. Newer versions will at first be hard-masked, but due to gcc-config, I've never had a problem installing them and even compiling nearly everything with them. At that early stage, there will definitely be packages that won't compile and you'll either need to switch back to an early gcc for those packages, or search bugzilla and apply necesary patches -- there's very often bugs already filed and patches already posted, since some people try it before gcc ever gets out of beta, upstream. Later, certainly as gcc-4.3 is now, it has been around long enough that many of those patches have already been applied in the newest versions of various ~arch packages in the tree. But if you're conservative, you can still install the newer versions and keep gcc-config pointed at your older versions for the system in general, only using the newer versions for testing or specific packages. There should be even less problems with that, and since you're using the old versions most of the time anyway, you won't run into the packages still broken with the new compiler. Just what I've found. It should be perfectly safe to have the new compilers installed but still point to the old ones for most stuff. If you do want to run the newer compilers for most of your system, you'll probably want to run ~arch at least, since otherwise you'll have lots of packages with broken compiles because the patches aren't yet backported to stable, since that version of gcc isn't yet close to being keyworded stable. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
