Re: gcc 3.3

[Fergus Henderson <fjh at cs dot mu dot OZ dot AU>]

On 30-Jul-2002, H. J. Lu <hjl@lucon.org> wrote:
> On Wed, Jul 31, 2002 at 07:41:09AM +1000, Fergus Henderson wrote:
> > 
> > P.S. I have a question of my own regarding symbol versioning.  Suppose I
> > have a C++ library `libfoo.so' that references libstdc++.so, and an
> > application `bar' that references both libfoo.so and libstdc++.so, and
> > suppose an ABI-breaking change is made to libstdc++.  A new version of
> > libstdc++ is installed; this has both the symbols for the new libstdc++
> > ABI, and symbols compatible with the old libstdc++ ABI, marked with the
> > old version number.  So `bar' continues to work.  Now, I try to compile
> > an application `baz' that references both libfoo.so and libstdc++.so.
> > `baz' uses the new version of the libstdc++.so ABI, but libfoo.so refers
> > to the old version.  To make `baz' work, I'd need to upgrade libfoo.so
> > to a version that uses the new version of the libstdc++.so ABI.  But that
> > would break `bar', wouldn't it?  (Or am I just hopelessly confused about
> 
> Why will the new libfoo.so break bar if it is binary compatible with
> the old libfoo.so?

It's not guaranteed to be binary compatible with the old libfoo.so.
The source for libfoo has not changed.
However, libfoo may have dependencies on libstdc++
that mean that libfoo's ABI changes if/when libstdc++'s ABI changes
and libfoo is recompiled with the new libstdc++.

For example, libfoo's interface may refer to types defined in libstdc++.
If the size of those types changes, then libfoo's ABI will change.

Even if libfoo's interface doesn't refer to any types defined in
libstdc++, there can still be problems.
The new libfoo.so refers to the new version of the libstdc++.so ABI.
But bar refers to the old version of the libstdc++.so ABI.
It may not be possible to combine the two in a single process.
For static objects whose size or layout has changed in incompatible ways,
it is not possible for both libfoo.so and bar to refer to the same object.

I guess things will work OK if you bump the major version number
on libfoo.so every time you compile it with a new version of libstdc++.
Then you can keep both the old and new versions of libfoo.so;
bar will continue to link with the old version, while baz
can link with the new version.

However, that approach will require either keeping around several
different versions of libfoo.so, or recompiling applications (such as bar)
that refer to it.  Furthermore, it means that library developers
are required to keep track of exactly which version of libstdc++
their binary libraries reference, so that they know to bump the major
version number when it changes.  They need to be aware that their
own ABI can change when they install a new version of libstdc++
which differs only in minor version number from the previous one.

-- 
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.