Re: [AMBER-Developers] rism - Netcdf problems?

From: David A Case <>
Date: Wed, 29 Jan 2014 08:16:30 -0500

On Wed, Jan 29, 2014, Timothy Giese wrote:
> There are 3 possible solutions:
> (1) Someplace (I don't know where yet - I haven't found it in nab.c)
> there is a -lnetcdf but that link line should have a -static so that it
> links to the .a instead of the .so

The "-lnetcdf" is in the FLIBS variable that is in config.h. The nab compiler
uses this to link. To see this:

    cd $AMBERHOME/AmberTools/test/nab
    nab -v

This shows how nab is linking programs.

The problem is that some people want to be able to compile/install Amber on
one machine, then move it somewhere else, changing just the $AMBERHOME
variable. This makes it hard (impossible?) to hard-code in the location
of the netcdf.a library, as we do with most of the other Amber programs.
Moving a compiler around is trickier than just moving around compiled
executables. (Note, e.g. that the gcc executable hard-wires the locations of
its libaries, as shown by "strings /usr/bin/gcc".)

The second part of the problem arose when we needed to have a relocatable
netcdef library in order to have the phenix connection. Before that, we just
compiled netcdf.a libaries, not making the .so version. Then, "-lnetcdf"
would pick up the .a version, and there was no need to resolve anything at
runtime. But now, "-lnetcdf" will get by default the .so library, leading to
Ross' observation.

We could try having -static be the default for nab (or maybe for many
other things as well?)

[Another possibility (more work) is to recognize that netcdf will always be a
requirement for nab, and to modify nab.c to getenv("AMBERHOME") and find the
netcdf.a lib that way. This would make Jason and Dan unhappy, since they want
to be able to link in netcdf from some package manager, and not use the one
in $AMBERHOME/lib.]

> before you run the executable

This certainly works, and is a minimal extra instrusion for the user. But it
is a new requirement and source of user errors.

> or
> (3) Find the -lnetcdf flag and replace it with the full path
> $AMBERHOME/lib/ (or .a)

We can certainly do that, and just tell users that they have to re-build
AmberTools (or at least nab) if they want to change locations.

Option (1) [enforcing -static for NAB] seems the most attractive, at least
until we find out the problems that causes!


AMBER-Developers mailing list
Received on Wed Jan 29 2014 - 05:30:02 PST
Custom Search