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