On 04/05/2011 09:48 PM, Orion Poplawski wrote:
> My thoughts:
>
> - According to
> http://linuxtesting.org/upstream-tracker/versions/netcdf.html, the
> main ABI problems with going from 4.1.1 -> 4.1.2 was:
>
> ncEnumType.h
> namespace netCDF
> [−] NcEnumType::ncEnumType (5)
> Change Effect
> 1 Value of field nc_INT64 has been changed from 8 to 10.
> Applications may execute another branch of library code.
> 2 Value of field nc_UBYTE has been changed from 5 to 7.
> Applications may execute another branch of library code.
> 3 Value of field nc_UINT has been changed from 7 to 9.
> Applications may execute another branch of library code.
> 4 Value of field nc_UINT64 has been changed from 9 to 11.
> Applications may execute another branch of library code.
> 5 Value of field nc_USHORT has been changed from 6 to 8.
> Applications may execute another branch of library code.
> [+] affected symbols (1)
> NcGroup::addEnumType ( std::string const& name, NcEnumType::ncEnumType
> basetype ) const:
> 2nd parameter 'basetype' has type 'NcEnumType::ncEnumType'.
>
> Kind of scary when constants change values.
>
> - Adding a new function does not require bumping the soname version
> because that is still backwards compatible.
>
> - Distribution and system maintainers must pay special attention to
> ABI compatibility. A significant version bump is a good indicator
> that this may happen and to look out for it. Conversely, "patch"
> level version changes are not expected to have ABI changes.
>
The change of ncEnumType reported by the tool is the false positive.
This is my fault. The issue is that after the clear installation of
netcdf-4.1.1 (./configure --enable-cxx-4, make, make install) there is
no definition for NC_UBYTE, NC_USHORT, NC_UINT and some other constants
in the header files:
4.1.1/include> grep -nR NC_UBYTE .
./ncEnumType.h:24: nc_UBYTE = NC_UBYTE, //!< unsigned 1 byte int
./ncType.h:32: nc_UBYTE = NC_UBYTE, //!< unsigned 1 byte int
But the source package of netcdf contains definitions for these constants:
#define NC_UBYTE 7 /* unsigned 1 byte int */
#define NC_USHORT 8 /* unsigned 2-byte int */
#define NC_UINT 9 /* unsigned 4-byte int */
#define NC_INT64 10 /* signed 8-byte int */
#define NC_UINT64 11 /* unsigned 8-byte int */
#define NC_STRING 12 /* string */
#define NC_VLEN 13 /* used internally for vlen types */
#define NC_OPAQUE 14 /* used internally for opaque types */
#define NC_ENUM 15 /* used internally for enum types */
#define NC_COMPOUND 16 /* used internally for compound types */
I've added these constants to the netcdf.h and rerun the tests [1]. The
CXX4 interface seems to be compatible between 4.1.1 and 4.1.2 and there
is no version bump for this reason:
4.1.1/lib> readelf -Wa libnetcdf_c++4.so.1.0.0|grep SONAME:
0x0000000e (SONAME) Library soname:
[libnetcdf_c++4.so.1]
4.1.2/lib> readelf -Wa libnetcdf_c++4.so.1.0.1|grep SONAME:
0x0000000e (SONAME) Library soname:
[libnetcdf_c++4.so.1]
But there are two changed constants in C interface: NC_WRITE (from 0x1
to 0x0001) and NC_NOCLOBBER (from 0x4 to 0x0004) used by ncopen and
nccreate functions. So, the soname has been bumped:
4.1.1/lib> readelf -Wa libnetcdf.so.4.0.0|grep SONAME
0x0000000e (SONAME) Library soname: [libnetcdf.so.4]
4.1.2/lib> readelf -Wa libnetcdf.so.7.0.1|grep SONAME
0x0000000e (SONAME) Library soname: [libnetcdf.so.7]
[1] Test results for libnetcdf
<http://linuxtesting.org/upstream-tracker/versions/netcdf.html>
--
Andrey Ponomarenko
Department for Operating Systems at ISPRAS
web: http://www.LinuxTesting.org
mail: aponomarenko@xxxxxxxxx
