This is actually a pretty complicated issue - whether to do static or
dynamic linking. I will not delve into all the pro's and con's for dynamic
vs. static, other than to note that dynamic linking grew out of demands on
multiprogramming systems (machines that are multitasking different
executables, for multiple users in the case of mainframes or minicomputers,
for one user in the case of workstations and pc's). I think of dynamic
linking as being done a bit better in windows environments, but that is
based on my past relatively good experience developing functionality in
dll's for windows. However, we are really not in a multiprogramming
situation when we run a parallel executable across multiple nodes in an
mpi-based cluster, and also the disk and memory space constraints that were
partly responsible for the evolution of dynamic linking are gone. So when I
started doing pmemd development, I advocated static linking, hang the size
of the executable and the slightly longer load time (can't take advantage of
functionality in shared libraries that happens to already be loaded in
memory) - the big advantage being that you are guaranteed to have a working
set of the library code on every machine running your executable. I shifted
radically in the other direction because several years ago there were major
problems in the static libraries for threading in redhat linux (basically
the thread stacks were pretty much guaranteed to overflow); this forced us
into dynamic linking. This problem should not still exist unless your
version of redhat is several years old. But dynamic linking remains a pain
in a cluster because the shared libraries have to be the correct versions
and they have to be available in an expected location on all the nodes. So
static linking is at least in theory simpler; sometimes finding all the
pieces you need to statically link in when building the executable can be
less than totally simple though. The other problem that one hits is that
when there are fixes to functionality in system libraries, you don't
automatically get the fix without recompiling unless you dynamically link.
I would expect we will continue to have some grief with all of this,
especially as we continue to get randomized by vendors like intel. I would
not issue a firm dictum one way or the other though - there are different
reasons on different platforms that may make one or the other method the
better choice, and things will continue to change in a completely
unpredictable manner (I am hoping for a move toward more simplicity in some
of this stuff, but history is not with me on this one).
- Bob Duke
----- Original Message -----
From: "Ross Walker" <ross.rosswalker.co.uk>
To: "'AMBER Mailing List'" <amber.ambermd.org>
Sent: Monday, June 08, 2009 9:41 PM
Subject: RE: [AMBER] sander error
> Hi John,
>
>> I am trying to run sander remotely through a ssh connection. I get an
>> error message (below) and sander doesn't run:
>>
>> sander: relocation error: sander: undefined symbol: ___svm1__acos2
>>
>> What does this mean? How do I address the problem?
>
> This generally means that the executable was not built statically and
> instead dynamically links to libraries. Then since the executable was
> built
> either the compiler version in you environment (defined by your
> LD_LIBRARY_PATH) and/or the version of MKL you are using has changed.
>
> The solution is to modify your environment to make sure it is setup to use
> the original version of the compiler, MPI and MKL libraries against which
> AMBER was built (difficult if some 'upgraded' the machine for you) or
> rebuild AMBER using the new environment.
>
> You can avoid this problem in future by building statically
> (provide -static
> flag to ./configure_amber) although some MPI implementations have issues
> with this but generally if you can you should always build statically.
>
> Good luck,
> Ross
>
>
> /\
> \/
> |\oss Walker
>
> | Assistant Research Professor |
> | San Diego Supercomputer Center |
> | Tel: +1 858 822 0854 | EMail:- ross.rosswalker.co.uk |
> | http://www.rosswalker.co.uk | PGP Key available on request |
>
> Note: Electronic Mail is not secure, has no guarantee of delivery, may not
> be read every day, and should not be used for urgent or sensitive issues.
>
>
>
>
>
> _______________________________________________
> AMBER mailing list
> AMBER.ambermd.org
> http://lists.ambermd.org/mailman/listinfo/amber
>
_______________________________________________
AMBER mailing list
AMBER.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber
Received on Tue Jun 09 2009 - 01:16:10 PDT
