Re: netcdf packages
Warren Turkal wrote:
> On Thursday 14 December 2006 11:09, Kevin B. McCarty wrote:
>> This is weird: if you install your new packages of netcdf, the existing
>> kst-plugins package (from Sid) on your system should automatically pick
>> up the new libnetcdf_c++.so.3 library and function properly, fixing the
>> crash. ÂI can only think of two reasons why this would not work:
>
> This could have something to do with the largefile support.
> The --enable-64bits enables support for netcdf files over 2GB. This probably
> changes some functions to return 64 bit instead of 32 bit numbers. Is the
> appropriate solution to bump the soname in this case?
At first I thought that might be a possibility. But in looking through
the configure.ac script, it seems that on Linux, --enable-64bits doesn't
actually do anything! Check out lines 570 - 621 of configure.ac, there
is no case for Linux. Also, netcdf-install.txt says this option has no
effect on Linux.
Maybe you are thinking of --disable-largefile, which "omits OS support
for large files (i.e. files larger than 2 GB)". But large files are
enabled by default as far as I can tell.
>> *) the soname of libnetcdf_c++.so has changed since the version in Sid
>> (in which case the binary package name must be changed and indeed kst
>> must then be rebuilt against the new library),
>
> I think this is what you are referring to.
>
> Was: libnetcdf.so.3.6.1
> Now: libnetcdf.so.3.6.2
Not that...
> You may also be referring to the links to those files, which are
> libnetcdf.so.3 in both cases.
Close. There should always exist a link with the same name as the
soname, pointing to the actual file, e.g.
libnetcdf.so.3 -> libnetcdf.so.3.6.2
You can find the actual soname built into the shared library file with
the following command:
objdump -x /usr/lib/libnetcdf.so.3 | grep SONAME
and it turns out to be "libnetcdf.so.3" for both your .debs and the ones
already in Sid.
>> *) OR, the soname was not changed even though it should have been.
>> (This is not an uncommon situation since C++ is hard to maintain a
>> stable ABI in.) ÂActually, I seem to remember you saying that shared lib
>> support was hacked into the Debian packages, meaning you will need to
>> care for the soname yourself.
>
> The sonames in the old version were an illusion. Should we diverge from
> upstream on the soname?
It's generally bad to diverge sonames from upstream if at all possible.
If it's necessary, one usually adds something Debian-specific on the
end, like libnetcdf.so.3d ("d" for Debian; I know, it's ugly) and
renames the package to something like libnetcdf3d.
I did a diff between netcdf-3.6.1/src/cxx and netcdf-3.6.2-beta4/cxx and
found some changes in netcdfcpp.h that look possibly problematic. For
instance, in the NcFile class, the add_dim() and add_var() methods have
been made virtual. In NcTypedComponent, a virtual destructor was added;
in NcError, an inline function, a static function, and two static
variables were added. I'm not sure if these changes are sufficient to
break the ABI. Trolltech has an FAQ about maintaining C++ ABI
compatibility if you want to look through it:
http://www.trolltech.com/developer/knowledgebase/362/
Another thing I noticed is that the old .debs have a single file
libnetcdf.so.3.6.1 including both C and FORTRAN code, while your new
.debs have separated it out into two files, libnetcdf.so.3.6.2 and
libnetcdff.so.3.6.2. This is going to break anything that depended on
the FORTRAN bindings in the old package, since those bindings are no
longer in the same file. Again, I don't know whether any of the
reverse-dependencies of libnetcdf3 use FORTRAN bindings, but you may
wish to check that.
For these two reasons, I would add the "d" to the end of the soname and
change the name of the package (only the runtime package, not the -dev
package) in order to be safe. Then, once the new .debs are eventually
uploaded (this will require a wait for the NEW queue due to the new
binary package name), request a rebuild of all depending packages.
Possibly you should ask for comments about this on debian-devel, we are
probably getting a little beyond the scope of debian-mentors. Maybe
also send these comments/questions along upstream...
Incidentally, if you run "ldd /usr/lib/libnetcdff.so.3" on the FORTRAN
bindings, it does not show libgfortran.so.1 nor libnetcdf.so.3, both of
which it uses symbols from. This should be fixed to ensure accurate
library dependencies. (In particular, you want to ensure that the
libnetcdf3 package picks up a Depends: libgfortran1 via
${shlibs:Depends}.) Similarly, libnetcdf_c++.so.3 should ideally also
have a built-in dependency on libnetcdf.so.3.
Will reply to your other email in a minute.
best regards,
--
Kevin B. McCarty <kmccarty@princeton.edu> Physics Department
WWW: http://www.princeton.edu/~kmccarty/ Princeton University
GPG: public key ID 4F83C751 Princeton, NJ 08544
Reply to: