Packages to rebuild after upgrading gcc on gentoo systems
TL;DR
I have a different take on this as a Gentoo user. While I agree with peterph's approach of "Let the System Decide," I disagree when it comes to an ABI Update. An ABI Update is sometimes a major shift in behavior. In the case of GCC 4.7, the ABI Change was the adoption of the new C++11 Standard, which peterph also pointed out.
Here is why I write this answer. I'm a standards junkie. I started in the web world when there were about 4 different browsers, and a plethora of tags in HTML that were only supported by certain browsers. At the time, all those tags increased confusion, and IMO made work harder. C++ has been standardized for this same reason, in short so that you can compile code that I write, and I can compile code that you write. If we chose not to follow a standard, we lose the freedom to share.
C++98 has been the approved Standard for 13 years. C++11 was ratified by the ISO Committee in 2011, and was completely integrated into GCC 4.7. See the current ISO status, and the new ISO Standard.
Why We Should Feel Privileged as Gentoo Users
As users of a source-based distribution, we have the unique opportunity to shape the future behavior of a package because we compile it before we use it. As such, to prepare for that opportunity, I feel that the following commands should be run, when updating to the new compiler:
emerge -ev system
gcc-config -l && gcc-config *new compiler name*
env-update && source /etc/profile
emerge -1v libtool
emerge -ev system
The first pass through system builds the new compiler, and it's dependencies, with the old compiler. The second pass through system rebuilds the new compiler and it's dependencies with the new compiler. Specifically, we want to do this so that our Build Chain takes advantage of the new features of the new compiler, if the Build Chain packages have been updated also... Some people replace the 2nd pass through system with the world set, although I find this to be overkill, as we don't know which packages already support the new standard, but we do want our build chain to behave sanely.
Doing this to at least the system set, prepares us to test every package that we compile against the new standard, because we use a rolling release. In this way, adding -std=c++11 to CXXFLAGS after updating the build chain allows us to test for breakage, and be able to submit bugs directly to either our bugzilla or upstream to the actual developers for the simple reason of:
Hey, your package blah blah breaks using the new C++ standard, and I've attached my build log.
I consider this a courtesy to the developers, as they now have time to prepare as the standard becomes more widely adopted, and the old standard is phased out. Imagine the commotion on the developer's part if he received hundreds of bugs, because he or she waited until the standard was phased out...
No other distribution that I know of can use this method as the actual package maintainers exist as middlemen before a patch or update can be used by the respective user community. We do have maintainers, but we also have the ability to use a local portage tree.
Regarding Insightful Thoughts Posted in the Bounty Request
I don't know if the bounty was posted because you all like my insightful, well thought out answers, but in an attempt at the bounty, I'll attempt to answer your insightful, well thought out bounty offering. First off, let me say in response that as a user of a source based distribution, I firmly believe what connects the dots are all the things you've asked for in your bounty request. Someone can be a great coder, but have crappy care for software. In the same way, there are people that are crappy coders that have great care for software.
Before I came here, I was an avid poster, over at the Gentoo Forums. I finally realized when I started coming here that everyone has some degree of some talent they can use. It's what they choose to do with it that makes the contributory difference. Some of us are Great writers (not I), so if you want to contribute to some project, but you don't or can't write code, or fix bugs, remember that great writers can write great documentation, or great Wiki Articles.
The standard is there for another reason: In a Community, certain rules are expected of it's members. Follow that statement here too. If I submit a fix, patch, enhancement etc and there are no standards, the patch will only work in the situations that I deem important, i.e if I'm using whizbang compiler 2.0, and the patch is built against whizbang compiler 1.0, it will fail. Since the effort is for a community, the community expects everything to work in most situations, so instead of forcing all users to upgrade to compiler 2, I can stipulate in a standard:
This package chooses to allow Backwards Compatibility with Whizbang Compiler 1.0
In this way, as a developer, crappy coder or not, I know that I must use or at least test against Compiler Version 1.0. As a user on the other hand, I can choose what I want to do. If I'm unhappy, I can request a patch, by submitting a bug, or the other extreme of "This software is a piece of crap!," and do nothing. Regardless, the user, and the developer understand the standard because it's been written.
Bridging the gap takes action of some form on a user's part, and that requires all the things you asked me and other's to comment on, and we must rely on the user community and their talents of all forms bridge that gap. If you choose to be one of the contributing users, I applaud you. For those of you who choose to be inactive, remember that if you want something fixed, the active ones need your input. So I'm telling you, don't be shy about submitting a bug, or telling us we need to update documentation, and if we're rude tell us, or find someone else, until you find your area of expertise.
Other Interesting Reading Related to This Topic
- The Biggest Changes in C++11 (and Why You Should Care)
- C++0x/C++11 Support in GCC
- News, Status & Discussion about Standard C++
It depends a lot on what kind of compiler upgrade you did. If it has been substantial, then everything should be recompiled*) because of possible changes in ABI by the compiler. In many cases it won't be necessary, but if your packages depend on something like C++11, then you might run into problems - see e.g. the Gentoo news about ABI change in GCC 4.7 or GCC bugzilla.
*) Note the emphasis on "recompiled" - it definitely doesn't make much sense to recompile (read rebuild) a Python or Perl application because you changed a C compiler. Unless it has a native component as well (which it well may).