On Tue, 2014-01-28 at 22:47 -0800, Ross Walker wrote:
> My guess is that you have a libnetcdf.so.* in your LD_LIBRARY_PATH.
>
> On my machine I do not:
>
> echo $LD_LIBRARY_PATH
> /opt/gnu/gcc/4.6.1/lib64:/opt/gnu/gcc/4.6.1/lib:/opt/cuda/5.0.35/lib:/opt/c
> uda/5.0.35/lib64:/opt/mpich2/gcc/eth/lib:/opt/gnu/gcc/4.8.1/lib64:/opt/gnu/
> gcc/4.8.1/lib:/opt/gnu/gmp/lib:/opt/gnu/mpc/lib:/opt/gnu/mpfr/lib
>
>
> none of which contain a libnetcdf.so.*
>
> Now there is a $AMBERHOME/lib/libnetcdf.so.7
>
> and if I add:
>
> export LD_LIBRARY_PATH=$AMBERHOME/lib:$LD_LIBRARY_PATH
>
> then things work fine.
>
> But we've never required such a thing as part of our installation
> procedure. Have things changed?
Yes, some things have changed -- I'll explain them as I understand them.
The problem is how the NetCDF library is linked in the FLIBS variable,
which is only used by NAB. FLIBS defines NetCDF library linking via
"-lnetcdf" regardless of whether a system NetCDF is used (via
--with-netcdf to configure) or if it uses the pre-compiled version
bundled with Amber. This approach appears to attempt dynamic linking by
default and falls back to static linking if that is unavailable. In the
past, static linking has been enforced by specifying the
$AMBERHOME/lib/libnetcdf.a archive to the linker, but I believe this was
changed to facilitate NAB relocation (i.e., you can move nab and the
rest of AmberTools and nab still works fine).
This was still usually OK since we only built the static NetCDF
libraries, anyway. However, the recent development of the MDGX API that
Pawel talked about at the meeting dictated that a shared NetCDF object
be available for creating a libmdgx.so file. Now that a shared NetCDF
library is always available, the shared object is always used. It can
be found at link-time thanks to the presence of -L$(LIBDIR) in the
linking lines, but as Tim pointed out this directory is not in the
standard ld search path (defined by /etc/ld.so.conf and
LD_LIBRARY_PATH), making this a run-time error.
A possible fix appears to be to replace -lnetcdf in FLIBS with
$(NETCDFLIB) inside configure, although I'm not sure what, if any,
effect this will have.
To add another wrinkle, linking the system NetCDF libraries, if you
choose to do so, enforces dynamic linking. I tried using the static
archives, but it did not work since those themselves depended on HDF5
dynamic libraries, leading to all kinds of grief (Amber excludes HDF5
from its NetCDF build, so does not encounter this problem).
I will play around with a couple fixes, but since all of my computers
have NetCDF installed via their package managers feedback would be
appreciated.
All the best,
Jason
--
Jason M. Swails
BioMaPS,
Rutgers University
Postdoctoral Researcher
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Wed Jan 29 2014 - 05:00:03 PST
