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

From: Jason Swails <jason.swails.gmail.com>
Date: Wed, 21 Oct 2015 15:49:15 -0400

On Wed, Oct 21, 2015 at 2:07 PM, Timothy J Giese <timothyjgiese.gmail.com>
wrote:

> If you skip the static library builds, then it doesn't matter one way or
> the other because the makefile will add the -fpic even if you don't...
>

​This is only true of the autoconf/automake packages we build (i.e.,
NetCDF, FFTW3, and XBLAS). The libraries *we* try to make require us to
explicitly set -fPIC, since we don't use autoconf.



> so it's more of a question of personal preference on your part.
> (It doesn't matter to me)
> Skipping the static library builds will speed the compilation of amber
> (well, not by very much), and I, further, can't imagine how you'd be
> able to make use of the static libraries (considering that the rest of
> your code is built with -fPIC) even if you DID make them, so I'm not
> seeing a real downside by eliminating them.
>

​The problem is that we currently do a little bit of a hodgepodge of
static/dynamic linking (e.g., libnetcdf.a is built into libsander.so, so
that the NetCDF symbols are built directly into that library). In fact,
all 3rd party libraries are linked into libsander that way, I think (blas,
lapack, ..., etc.), so that all you ever have to link when using the sander
API is -lsander (rather than needing -lsander -lnetcdf -lnetcdff -lblas
-llapack -lsqm).

Since it never broke for any OS I'd used before, and nobody had ever
reported problems with it, I didn't realize that libgfortran.a was
sometimes built only with position dependent code (and that this was
supposed to be "common practice" in Linux, since it's entirely uncommon in
my experience).

What's going to make this difficult to phase out of Amber completely is
that we use the same objects to build both shared and static versions of
our libraries, and separating them will take a non-negligible effort by
some person familiar enough with both the Amber build and the Linux concept
of how shared/static libs should be built.

I *think* if we offer the ability to toggle "--enable-static=no" in the
NetCDF build and then just always link libnetcdf.so, we'll solve all of our
potential PIC/PDC-related issues, but I'm not sure. And since I don't have
a machine where I can actually test whether an idea will work or not, I
don't want to risk changing a bunch of stuff only to realize I dug in the
wrong direction.​


​Thanks!
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 Oct 21 2015 - 13:00:04 PDT
Custom Search