[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


> 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:


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 
    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 Rew                                         UCAR Unidata Program
address@hidden                      http://www.unidata.ucar.edu

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

NOTE: All email exchanges with Unidata User Support are recorded in the Unidata inquiry tracking system and then made publicly available through the web. If you do not want to have your interactions made available in this way, you must let us know in each email you send to us.