GDAL 1.8.x and beyond
Hi folks
in experimental I'm exploiting the possibility of adopting symbol tracking
in order to avoid the perennial reissuing of a new versioned source
package at every new major release, with the costly binNMU jobs batching,
which is quite annoying.
Basically this is a well-known and quite old problem, due to possible
breakage of the C++ interface from one version to another. The C++ classes
are exported and mixed up with the very stable C API within the same library.
My idea is using version tracking (see [1]) starting from 1.8.1
version for both C and C++ global symbols and possibly a version script [2]
to add a suitable symbol versioning (e.g. @GDAL_1.8 for current 1.8.1 version)
at each new release (with possibly source patches whenever breakages would
happen).
My aim is dropping source versioning in packages and returning
to a more sane and simple libgdal<SONAME> binary, with a conventional -lgdal
as linking argument and so on. That will require another final round of binNMUs
to normalize the archive.
At the same time, 1.8.1 will be the first version which should solve
the old problem of linking both geotiff, tiff and gdal within the same
binary, something that annoyed since years Orfeotoolbox folks and possibly
others.
Note: the new library will NOT be binary-compatible with third-parties
closed binaries. At least, I know it will probably be not more compatible with
GAMMA SAR and Interferometry Software [3] which does not distribute its own
copy of gdal.
Ideas and comments?
[1] http://wiki.debian.org/Projects/ImprovedDpkgShlibdeps
[2] http://sourceware.org/binutils/docs/ld/VERSION.html#VERSION
[3] http://www.gamma-rs.ch/no_cache/software.html
--
Francesco P. Lovergine
Reply to: