[netCDF #AOO-337010]: libnetcdf/hdf5/curl linkage

> On 11/12/2009 08:15 AM, Unidata netCDF Support wrote:
> >> Testing with 4.1.0.  The netcdf libraries (libnetcdf.so,
> >> libnetcdf_c++.so, and libnetcdff.so) should get directly linked against
> >> the hdf5 library.
> >
> > Is this not happening for you? Are you doing a shared or static library 
> > build?
> 
> static and shared, hdf5 only (no hdf4).  I had to patch
> libsrc4/Makefile.in to add -lhdf5_hl and -lhdf5 to libnetcdf_la_LIBADD.

Howdy Orion!

Thanks for pointing out this problem. I see from a more careful reading of the 
Automake manual that I need to set libnetcdf_la_LIBADD *and* LDADD. It seems 
that the LIBADD is for the library and the LDADD is only for test programs. I 
have fixed this in the C, C++, and F90 directories.

Somehow I have a feeling that there's a better way to do this in Automake. I 
have asked the automake gurus for guidance.

> Build logs are here:
> 
> http://kojipkgs.fedoraproject.org/packages/netcdf/4.1.0/0.5.2009111008.fc13/data/logs/i686/build.log
> 
> Link is:
> 
> /bin/sh ../libtool --tag=CC   --mode=link cc  -O2 -g -pipe -Wall
> -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector
> --param=ssp-buffer-size=4 -m32 -march=i686 -mtune=atom
> -fasynchronous-unwind-tables -version-number 6:0:0  -o libnetcdf.la
> -rpath /usr/lib nc4attr.lo nc4internal.lo nc4var.lo nc4dim.lo ncfunc.lo
> nc4file.lo error.lo nc4grp.lo nc4type.lo nc4hdf.lo
> ../libsrc/libnetcdf3.la ../libncdap4/libncdap4.la
> ../libsrc/libnetcdf2.la  -lhdf5_hl -lhdf5
> 
> libtool: link: cc -shared  .libs/nc4attr.o .libs/nc4internal.o
> .libs/nc4var.o .libs/nc4dim.o .libs/ncfunc.o .libs/nc4file.o
> .libs/error.o .libs/nc4grp.o .libs/nc4type.o .libs/nc4hdf.o
> -Wl,--whole-archive ../libsrc/.libs/libnetcdf3.a
> ../libncdap4/.libs/libncdap4.a ../libsrc/.libs/libnetcdf2.a
> -Wl,--no-whole-archive  -L/lib -lcurl -lhdf5_hl -lhdf5  -m32 -march=i686
> -mtune=atom   -Wl,-soname -Wl,libnetcdf.so.6 -o .libs/libnetcdf.so.6.0.0
> 
> With this change the packaging warnings I get are:
> 
> netcdf.i686: W: unused-direct-shlib-dependency
> /usr/lib/libnetcdf_c++.so.5.0.0 /usr/lib/libcurl.so.4
> netcdf.i686: W: unused-direct-shlib-dependency
> /usr/lib/libnetcdf_c++.so.5.0.0 /usr/lib/libhdf5_hl.so.6
> netcdf.i686: W: unused-direct-shlib-dependency
> /usr/lib/libnetcdf_c++.so.5.0.0 /usr/lib/libhdf5.so.6
> netcdf.i686: W: unused-direct-shlib-dependency
> /usr/lib/libnetcdf_c++.so.5.0.0 /lib/libm.so.6
> netcdf.i686: W: unused-direct-shlib-dependency
> /usr/lib/libnetcdff.so.5.0.0 /usr/lib/libcurl.so.4
> netcdf.i686: W: unused-direct-shlib-dependency
> /usr/lib/libnetcdff.so.5.0.0 /usr/lib/libhdf5_hl.so.6
> netcdf.i686: W: unused-direct-shlib-dependency
> /usr/lib/libnetcdff.so.5.0.0 /usr/lib/libhdf5.so.6
> netcdf.i686: W: unused-direct-shlib-dependency
> /usr/lib/libnetcdff.so.5.0.0 /lib/libm.so.6
> netcdf.i686: W: unused-direct-shlib-dependency
> /usr/lib/libnetcdff.so.5.0.0 /lib/libgcc_s.so.1
> 
> explanation:
> The binary contains unused direct shared library dependencies.  This may
> indicate gratuitously bloated linkage; check that the binary has been
> linked with the intended shared libraries only.

But wait, does this not say that the C++ library should not be linked to HDF5?

> 
> The link line from libnetcdf_c++.so:
> /bin/sh ../libtool --tag=CXX   --mode=link c++  -O2 -g -pipe -Wall
> -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector
> --param=ssp-buffer-size=4 -m32 -march=i686 -mtune=atom
> -fasynchronous-unwind-tables      -version-info 5:0:0   -o
> libnetcdf_c++.la -rpath /usr/lib netcdf.lo ncvalues.lo
> ../libsrc4/libnetcdf.la
> 
> libtool: link: c++ -shared -nostdlib
> /usr/lib/gcc/i686-redhat-linux/4.4.2/../../../crti.o
> /usr/lib/gcc/i686-redhat-linux/4.4.2/crtbeginS.o  .libs/netcdf.o
> .libs/ncvalues.o   -Wl,-rpath
> -Wl,/builddir/build/BUILD/netcdf-4.1-snapshot2009111008/libsrc4/.libs
> ../libsrc4/.libs/libnetcdf.so -L/lib -lcurl -lhdf5_hl -lhdf5
> -L/usr/lib/gcc/i686-redhat-linux/4.4.2
> -L/usr/lib/gcc/i686-redhat-linux/4.4.2/../../.. -lstdc++ -lm -lc -lgcc_s
> /usr/lib/gcc/i686-redhat-linux/4.4.2/crtendS.o
> /usr/lib/gcc/i686-redhat-linux/4.4.2/../../../crtn.o  -m32 -march=i686
> -mtune=atom   -Wl,-soname -Wl,libnetcdf_c++.so.5 -o
> .libs/libnetcdf_c++.so.5.0.0
> 
> So libtool is grabbing all of the libraries from libnetcdf.la and adding
> them to the gcc link line.  So I suppose this is a libtool issue.  Not
> nearly as big a deal as the not linking with hdf5 issue.

I just put out a new snapshot release. Why don't you give it a try and see if 
we are converging on a solution:
ftp://ftp.unidata.ucar.edu/pub/netcdf/snapshot/netcdf-4-daily.tar.gz

> 
> 
> Also:
> netcdf.i686: W: shared-lib-calls-exit /usr/lib/libnetcdf.so.6.0.0
> exit@GLIBC_2.0
> netcdf.i686: W: shared-lib-calls-exit /usr/lib/libnetcdf_c++.so.5.0.0
> exit@GLIBC_2.0
> This library package calls exit() or _exit(), probably in a non-fork()
> context. Doing so from a library is strongly discouraged - when a
> library function calls exit(), it prevents the calling program from
> handling the error, reporting it to the user, closing files properly,
> and cleaning up any state that the program has. It is preferred for the
> library to return an actual error code and let the calling program
> decide how to handle the situation.
> 
> 

We do use one exit() in the classic library, but it's a feature not a bug. In 
the v2 API it's possible to instruct the library to exit on error.

Thanks,

Ed


Ticket Details
===================
Ticket ID: AOO-337010
Department: Support netCDF
Priority: Normal
Status: Closed