[gdal-dev] libtool numbering policy

[Bas Couwenberg]

On 2016-06-14 11:29, Even Rouault wrote:
> A ticket ( https://trac.osgeo.org/gdal/ticket/6542 ) has been raised 
> about
> libtool SONAME having not changed between GDAL 2.0.X and GDAL 2.1.0 due 
> to
> incrementing both LIBGDAL_CURRENT and LIBGDAL_AGE .
> This was raised also in https://trac.osgeo.org/gdal/ticket/4543
> 
> Our, more or less implicit, policy up to now was to take just into 
> account the
> C ABI, and not the C++ one. Any opinion if we should change it to take 
> into
> account the C++ ABI as well ?
> 
> If doing that, I can see
> - pros: new policy would match the expectations of the C++ API users
> - cons: C API users would see soname changes that don't affect them, 
> requiring
> recompilation/relinking

As long as the C & C++ APIs are provided by a single library, it makes 
sense to base the libtool versioning on the C++ API since that changes 
most often.

In Debian we mark the libgdal C++ symbols and add a dependency on the 
version specific virtual ABI package provided by the libgdal20 package 
to all packages that use any of the C++ symbols. Most reverse 
dependencies of GDAL use (some) C++ symbols, requiring a rebuild of 
these packages for every new release of GDAL uploaded to Debian. Only 
the gmt, imposm, mapcache, mapserver, ncl, osmium, postgis, xastir, 
grass & pyosmium packages don't use any C++ symbols (10 out of 37).

It would be great if the other reverse dependencies would limited 
themselves to the C API, but that seems an unrealistic desire. GEOS 
reverse dependencies don't manage that either, although most GEOS rdeps 
use the C API with a few that (also) require the C++ API.

> Another approach would be to have a libgdal_c.so with C ABI only and
> libgdal.so with the rest, ala GEOS, but it is not obvious that the cost 
> to
> restructure the GDAL code to implement that, and to existing external 
> code to
> adapt for this change, would be worth the advantages.

It is a cleaner approach, but because it's so invasive I would postpone 
that change to GDAL 3.0 making it of no use in the short term.

I'm generally in favour of this option as the proper long term solution. 
It will simplify the packaging by removing the need for the virtual ABI 
package.

Kind Regards,

Bas