Hi Warren,
Warren Turkal wrote:
> On Wednesday 13 December 2006 10:55, Warren Turkal wrote:
>> I think that we should just go for it. W00T!
OK, you've convinced me that compiling with gfortran shouldn't be a
problem. (But please try to make sure that maintainers of any new
packages introduced depending on the FORTRAN bindings of netcdf are
aware of the issue.)
> KST can actually plot netcdf graphs after the upgrade in library. It just
> crashed on all my netcdf files before. This is another reason to upgrade the
> library.
>
> Unfortunately, it lookes like kst will have to be relinked with the new
> library to work without crashing. It uses the c++ binding. I suspect anything
> using that binding would need to be recompiled as well. Did the netcdf lib
> ever go through the C++ ABI change?
I think it must have at least been built with the new g++:
benjo (sid)[2]:~% apt-cache show libnetcdf++3| grep Depends
Depends: [...], libstdc++6 (>= 4.1.0)
^^^^^^^^^^
According to packages.qa.debian.org, the version of kst in Sid/Etch was
built in November '06, long after the current version of netcdf was
uploaded (in July '06). So any problems with kst's use of netcdf in
Sid/Etch are not likely to be due to the C++ ABI transition.
I don't quite understand the exact problem you are facing, though. If
I have read your email correctly, you see the following:
a) libnetcdf++3 package from Sid, kst-plugins package from Sid ==> Crash
b) libnetcdf++3 package from your new .debs, kst-plugins package from
Sid ==> Crash
c) libnetcdf++3 package from your new .debs, kst-plugins package rebuilt
against your new .debs ==> Works OK
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:
*) 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),
*) 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.
Here are some other comments regarding your -beta4-1~pre3 .debs, now
that I've taken the time to look at them. (Note, I have only looked at
the .debs, not at the source package.)
1) Why did you make the libnetcdf++3 package into a dummy package and
move the C++ bindings into the libnetcdf3 package? If the soname of the
C++ package needs to evolve faster than that of the C/FORTRAN bindings,
as I speculated above, this would be a really good reason to keep the
C++ bindings in a separate package.
2) I don't think there should be info files in libnetcdf++3 (regardless
of whether it is a dummy package or a shared library package). I see
you do ship the info files in libnetcdf-dev as well (where they should
be), but they should be in /usr/share/info, not under
/usr/share/doc/libnetcdf-dev where info won't look for them.
(On second look, you already have noticed this problem.)
3) The static libraries (lib*.a) must be shipped in the libnetcdf-dev
package, not in the runtime library (libnetcdf3) package. Please do not
ship libtool *.la files at all, as has been requested many times by the
release team. See for instance the discussion at bug #400140.
4) Your libnetcdf-dev package is missing a Depends line. It should
Depend at least upon the netcdf shared library package(s), upon any
*-dev packages that ship files #included by its header files, and upon
any *-dev packages that ship static libs depended upon by netcdf static
libs. (The last is slightly controversial, since there are people who
hate static libraries; for that you might be able to use a Recommends
instead of Depends.)
5) Wherever you Conflict against an old package (such as libnetcdf-dev's
Conflicts: netcdf-dev, netcdfg-dev (<< 3.6.2)) because of file
conflicts, you also need a Replaces line with similar contents. This is
because under some circumstances, dpkg will try to unpack a new package
before completely removing an old package that is conflicted against.
Some of these issues could have been caught by comparing the contents of
the netcdf binary packages in Sid and your new packages. I find that
debdiff is a really useful tool for such comparisons, though of course YMMV.
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
Attachment:
signature.asc
Description: OpenPGP digital signature