From: David A Case <case.biomaps.rutgers.edu>
Date: Tue, 11 Jun 2013 21:27:48 -0400
{moving this discussion to amber-developers}
On Tue, Jun 11, 2013, Jason Swails wrote:
>
> This actually makes a lot of sense now. It was definitely pulling the
> libnetcdf.a file from /usr/lib
If I understand it, this sounds like incorrect behavior. Amber should not be
using /usr/lib/libnetcdf.a unless the user explicitly asks for it with
the --with-netcdf flag.
The sander Makefile says:
.... -L/home/case/amber12/lib -lnetcdf
but I'm thinking this might not be correct -- is the "-L" directory searched
before or after places like /usr/lib? (I'm afraid that the "-L" directory
comes at the end of LDFLAGS, not at the beginning.)
> More recent versions of NetCDF
> actually bundle the Fortran and C symbols in separate libraries.
This is the reason why it seems generally safer to build our own netcdf
libraries than trying to guess or assume what might be in some system library.
(Same argument as for MPI libraries.)
I suppose this might be wrong, and that we should figure out the package
names for various linuxes and Macs and cygwin, and just require that users
install those packages. But I'd like to keep the size of the list of
packages needed for Amber down to ones that really are standard almost
everywhere--not sure if netcdf yet falls into that category.
And what we have now is in some ways the worst (at least the most complex)
of all options--trying to support *both* the locally-compiled netcdf and a
system-built one. And I've not yet been convinced by arguments about why
it's important to have a --with-netcdf flag.
[Of course, these considerations also apply to blas, lapack, MPI, FFTW, etc.
But with these others, there are good performance reasons to want to use a
"vendor-supplied" library. I'm guess I'm not sure if there are any similar
performance advantages to be had with "optimized" netcdf libraries.]
