d hongqian wrote: > I want to know the version of gcc 's mean. For example: the gcc > 3.4.6, what's the difference between the 3.4.6 and 3.4.5. > and what's difference between 3.3.0 and 3.2.0 and what's the > difference between 3.0.0 and 4.0.0. The first two numbers correspond to the branch of development. 4.0.x is one branch, 4.1.x another, 4.2.x another, and so on. Releases are always done from branches, with the trunk representing the next higher version. Currently the mainline (trunk) is 4.4, and the 4.3 and 4.2 branches are open for active development. This means all patches go onto the trunk first and are then backported to 4.3 and 4.2 if they fix regressions. The 4.1 branch is also technically open but it is likely there will never be another release from it. All other branches are long closed and will never see any changes. The gcc homepage always lists the current status of trunk and branches. The development goes in stages, corresponding to the cycle of creating a new release branch off of the trunk and then bumping the version number of what the trunk represents. That newly created branch then becomes a release branch eligible for regression and doc fixes only, and the trunk goes into stage 1 which means new features that people have been working on are added/merged. See <http://gcc.gnu.org/develop.html> for details about the stages of development and branching. Generally point releases along a branch (i.e. moving from x.y.z -> x.y.z+1) are primarily to fix regressions and shouldn't introduce any major new features, nor add support for any new targets, nor remove support for any existing targets. Also ABI compatibility on a branch is more or less guaranteed, although there have been some very minor cases in the past where a patch on a point release accidentally (and unknowingly at the time it was committed) caused an ABI regression in some minor obscure corner case that didn't affect many people -- these kinds of ABI changes can often be extremely hard to notice. But releases across branches can have huge changes, especially changes that affect the ABI. For example between 3.3 and 3.4 the C++ parser was completely rewritten and as a result many aspects of C++ support changed, most notably standards conformance and the ABI. A change in ABI means that you cannot mix binary code that has been compiled between the two versions, so if you had any libraries compiled with 3.3 you had to rebuild them with 3.4 in order to use 3.4 with new code. For this reason distros tend to pick one branch and stick with it for the lifetime of their major release, because for a distro switching in mid flight to a new gcc branch that is ABI compatible would be a nightmare. Some of the gcc target libraries use symbol versioning, notably libstdc++ and libgcc. This allows new releases to introduce new features while still allowing to be binary compatible with older releases -- but of course not in the other direction. This doesn't automatically guarantee backwards compatibility throughout all time however. For example in conjunction with the C++ changes previously mentioned between 3.3 and 3.4, libstdc++ had a "soname bump" where it went from libstdc++.so.5 to libstdc++.so.6. This represents a discontinuous step in compatibility, i.e. there's no way to run old code linked with libstdc++.so.5.0.5 with libstdc++.so.6.0.0. The difference in soname means they can both exist on a system, and code compiled with g++ 3.3 will link with the .5 version and code linked with g++ 3.4 and later will link with the .6 version. The implication is that if you upgraded to 3.4 you would have to keep 3.3 around (or at least the target libraries if not the compiler itself) until you'd recompiled everything. There's details about library versioning at <http://gcc.gnu.org/onlinedocs/libstdc++/17_intro/abi.html>. Each branch has a changes document where major changes are listed: <http://gcc.gnu.org/gcc-2.95/features.html> <http://gcc.gnu.org/gcc-3.0/features.html> <http://gcc.gnu.org/gcc-3.1/changes.html> <http://gcc.gnu.org/gcc-3.2/changes.html> <http://gcc.gnu.org/gcc-3.3/changes.html> <http://gcc.gnu.org/gcc-3.4/changes.html> <http://gcc.gnu.org/gcc-4.0/changes.html> <http://gcc.gnu.org/gcc-4.1/changes.html> <http://gcc.gnu.org/gcc-4.2/changes.html> <http://gcc.gnu.org/gcc-4.3/changes.html> <http://gcc.gnu.org/gcc-4.3/porting_to.html> > If I want to update my gcc, how many things should also be update > so that the system could be stable. There's no way to answer that without a great deal more detail. It depends on: - whether you're talking about a point release on the same branch or moving to a new branch, and if so it depends on the nature of the changes that occurred on that branch - what languages you use, for example the C ABI changes much less frequently than the C++ ABI; another example is g77 which was completely removed and replaced by gfortran in 4.0 - what target you use: some targets experience ABI changes across branches while others don't; an example might be transitioning from 80 to 128 bit long double as the default, or changes in alignment. - whether your target is even supported on a branch, or whether a given language supports your target on a branch; for example, gcj support for ARM EABI is new in 4.3 - whether you plan to depend on a distro or whether you are building a system from scratch yourself - whether you have old or invalid code that is rejected as invalid by the newer and stricter gcc versions - whether you have code that links with third party libraries that are out of your control, possibly without source If you just want to evaluate a new version of gcc, simply build and install it into its own isolated --prefix away from /usr or /usr/local. You can have as many versions of gcc installed in parallel as you like using this method. The hard part of doing this is not figuring out how to put gcc in its own prefix but rather dealing with the runtime consequences of library search order, usually through LD_LIBRARY_PATH. Using the linker option -rpath here could be a good idea if you have lots of various parallel gccs, as it saves having to put all of them in LD_LIBRARY_PATH and suffer the resulting pain of the wrong version of something being found for a given executable at runtime. Brian
