[Gdal-dev] Release 1.4.0

Frank Warmerdam warmerdam at pobox.com
Wed Nov 15 10:55:19 EST 2006

Christopher Barker wrote:
> Simon Perkins wrote:
>> On linux where it's more common to use a central shared GDAL library, it
>> seems that we typically don't change the library soname. It's been
>> libgdal.so.1 for a long time now. I have no idea if the latest GDAL is
>> actually binary compatible with the earliest version that used that
>> name. Has that been a problem for anyone?
> Ideally,
> libgdal.so.1 would be a link to libgdal.so.1.4, which would be a link to 
> libgdal.so.1.4.0 ---
> The libgdal.so.1 link would change to the latest version, as newer ones 
> were installed, but the older ones could stick around, and could be 
> linked to if need be.
> In general, the goal is for binary compatibility between minor version 
> number changes. (i.e 1.4.1 should be binary compatible with 1.4.0)

Christopher / Simon,

Currently there are three naming conventions used.  The one that Christopher
describes is used on Unix when GDAL is built --without-libtool.   When
built with libtool something somewhat similar is used but with funkier
verison numbers that don't correspond directly to release numbers.

On windows the DLL is always called GDAL13.DLL since the GDAL 1.3.0 release.

I'm not planning any changes for the unix versioning.

But for windows, I can't help but think we should be doing something smarter.
However, lacking soft links I'm not sure how to get the same flexiblity as
we have on unix.  I'd like to have windows DLLs with names like
GDAL140.DLL but I'd also like a way of understanding that applications using
the GDAL C API can generally use any relatively recent GDAL DLL.  Is there
a normal way of handling this sort of thing on windows?  Is it goig to be
a lot of work?

Best regards,
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | President OSGeo, http://osgeo.org

More information about the Gdal-dev mailing list