* Re: What does the version number of gcc mean ?
2008-03-20 7:57 What does the version number of gcc mean ? d hongqian
2008-03-20 11:42 ` John Love-Jensen
@ 2008-03-20 12:25 ` Brian Dessent
1 sibling, 0 replies; 3+ messages in thread
From: Brian Dessent @ 2008-03-20 12:25 UTC (permalink / raw)
To: d hongqian; +Cc: gcc-help
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
^ permalink raw reply [flat|nested] 3+ messages in thread