Re: [AMBER-Developers] Problems with AmberTools 15 and netcdf-fortran-4.2 compile

From: Jason Swails <>
Date: Thu, 22 Oct 2015 14:27:27 -0400

On Wed, Oct 21, 2015 at 7:11 PM, Timothy J Giese <>

> On 10/21/2015 03:49 PM, Jason Swails wrote:
> > API is -lsander (rather than needing -lsander -lnetcdf -lnetcdff -lblas
> > -llapack -lsqm).
> >
> Don't get me wrong -- I really don't care

​You don't have to qualify :). Your insights are helpful and appreciated.

> -- but I'm just going to point
> out the obvious: You already tell people to source a bash (or csh
> script), so you could just as easily define a variable in that script
> export SANDER_LIBS="-lsander -lsqm -lnetcdf -lnetcdff -lblas -llapack"
> So that people can just add
> CPPFLAGS="-I${AMBERHOME}/include \
> to whatever they are compiling.
> But, you know, whatever.

​The real reason things are the way they are is because that's simply how I
got them to work. sander is a *beast*, built from components scattered all
over the place (libsqm, libpbsa, librism, libfftw3, libnetcdf, libblas,
liblapack, ...) and most of these libraries are Amber-built, static
archives (and a lot of the libs are linked in multiple places, like RISM
and PBSA that go into their standalone programs, nab, and sander).

So I *started* from a mostly-statically-linked sander executable, adjusted
the linking command to create a .so, and then added -fPIC everywhere so I
could get libsander to work with other PIC code (the main target here being
Python). So is just a small perturbation of how sander is
built (it was already a lot of wrangling to get it even that far).

I'd like to improve things, but I'm wary of breaking something that *just
works* (Ross's report was the first I'd gotten of this not working) and
getting stuck in a time sink.​


Jason M. Swails
Rutgers University
Postdoctoral Researcher
AMBER-Developers mailing list
Received on Thu Oct 22 2015 - 11:30:04 PDT
Custom Search