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
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
