Re: Patch: RFC: bump libtool version

[Andrew Haley <aph at redhat dot com>]

Matthias Klose writes:
 > Andrew Haley schrieb:
 > > Matthias Klose writes:
 > >  > Tom Tromey schrieb:
 > >  > > Matthias pointed out on irc that we ought to bump the libgcj version
 > >  > > on trunk.  I think we also need this on the RH 4.1 merge branch.
 > >  > > 
 > >  > > I thought I would see if there are any comments before I check this in.
 > >  > 
 > >  > one more thing; currently we do not change the versioned gcj subdir when
 > >  > we change the libgcj soversion. At least for distributions like debian
 > >  > and ubuntu that means that we do have file conflicts if we bump the
 > >  > libgcj soversion and keep the gcc version (having packages like libgcj7
 > >  > and libgcj8).
 > > 
 > > Why?  What exactly causes the problem?
 > 
 > The ABI/API version of a shared library is encoded in the package
 > name; this is standard technique used in these distributions. when
 > the soversion is changed, the package with the old soversion can be
 > kept installed together with packages depending on that
 > version. Until all packages depending on the old library package
 > are rebuilt you can have both library packages installed together
 > (if files in those library packages don't conflict). If you
 > currently backport a new libgcj to a released gcc version, you do
 > have the file conflicts in /usr/lib/gcj-<gcc-version>, although the
 > library ABI changed, not anything of the gcc/gcj ABI. 

The library ABI has changed, along with the gcc/gcj ABI, and therefore
a new soname is needed: of that there is no doubt.

Also, install/lib64/gcj-<version> needs a suitable version name; for
RH versions we call it <version>-rh<blah> to make sure people don't
confuse it with an FSF release.  This is important.

 > You could avoid these problems installing into
 > /usr/lib/libgcj<libgcjsoversion>. You don't have this problem if
 > you do not support partial upgrades or rebuild your distribution
 > from scratch.

In practice I doubt very much that any of this will really matter to
most users, as most packages are built with indirect-dispatch anyway.

Andrew.