[netCDF #IWZ-281549]: netcdf 4.2 soname bump

Orion,

> On 01/12/2012 08:53 PM, Unidata netCDF Support wrote:
> > Hi Orion,
> >
> >> The soname version was bumped in 4.2-rc1 to 8.  Why?  It appears that it is
> >> completely compatible with version 4.1.3 as shown by the attached report.
> >
> > I actually changed it back to 7.1.1 earlier today in our snapshot release 
> > (coincidentally
> > a little before you sent your question), because we decided to disable the 
> > diskless file
> > implementation, which was not finished and not ready for prime time.  To 
> > support
> > diskless files, a new constant had been defined in netcdf.h, NC_DISKLESS, 
> > as a flag to
> > nc_create(), which we thought had changed the interface to that function, 
> > requiring
> > bumping the soname version.
> >
> > I may have been misinterpreting the meaning of "interface change", but it 
> > seems that
> > with the 4.2-rc1 library, you could write code that wouldn't link with a 
> > 4.1.3 library,
> > due to the addition of the new mode flag.  In any case, you'll find that 
> > constant gone
> > in the current snapshot and the next release.
> 
> Great.  One generally only bumps the soname version when you introduce a
> backwards incompatible change.  You don't really worry about forward
> compatibility.
> 
> See:
> 
> http://sourceware.org/autobook/autobook/autobook_91.html

That's a better explanation than what I had been using from the gnu libtool
manual, from notes Ed provided:

  http://www.gnu.org/s/libtool/manual/html_node/Updating-version-info.html

From that, I thought the situation with the new NC_DISKLESS mode for 
nc_create() put us in situation 2:

 2. Programs using the previous version may use the new version as drop-in   
    replacement, but programs using the new version may use APIs not present in 
    the previous one. In other words, a program linking against the new version 
    may fail with “unresolved symbols” if linking against the old version at 
    runtime: set revision to 0, bump current and age.

> Are you really wanting to be using --version-number or --version-info?
> 
> The change you made (going to 8:0:2) seemed correct if you were using
> --version-info (bumping the interface and age, resetting revision)

I think we should be using version-info, but the version-info/version-number 
confusion is confounded by Ed's comment in liblib/Makefile.am, which shows
we're actually using -version-number:

  # These linker flags specify libtool version info.
  libnetcdf_la_LDFLAGS = -version-number 7:1:1

> From an old libtool changelog:
> New command line flag -version-number for porting old libraries to libtool.
> 
> -version-info current[:revision[:age]]
> If output-file is a libtool library, use interface version information
> current, revision, and age to build it (see Versioning). Do not use this flag
> to specify package release information, rather see the -release flag.
> 
> -version-number major[:minor[:revision]]
> If output-file is a libtool library, compute interface version
> information so that the resulting library uses the specified major, minor and
> revision numbers. This is designed to permit libtool to be used with existing
> projects where identical version numbers are already used across operating
> systems. New projects should use the -version-info flag instead.
> 
> If you do change to --version-info, you would need to change to --version-info
> 9:0:2 which would create libnetcdf.so.7.2.0 and still have a soname of
> libnetcdf.so.7.

That's helpful, thanks.  Based on your advice, I'm changing the 
liblib/Makefile.am line to

libnetcdf_la_LDFLAGS = -version-info 9:0:2

--Russ

Russ Rew                                         UCAR Unidata Program
address@hidden                      http://www.unidata.ucar.edu



Ticket Details
===================
Ticket ID: IWZ-281549
Department: Support netCDF
Priority: Normal
Status: Closed