AMBER Archive (2006)

Subject: RE: AMBER: amber9 compilation problems on EM64T xeon system

From: Ross Walker (ross_at_rosswalker.co.uk)
Date: Thu Jul 06 2006 - 22:06:15 CDT

Hi Hayden,

> However, when I leave out the "static" flag I get this error
> (following an
> apparently error-free compilation):"
> ./../exe/sander: error while loading shared libraries:
> libcxaguard.so.5:
> cannot open shared object file: No such file or directory
> ./Run.dmp: Program error
> make: *** [test.sander.BASIC] Error 1
> "

You should see if you can locate where libcxaguard.so.5 is on your system.
On my machine this is part of the ifort v9.0 installation I use. The path to
this and other required libraries needs to be in your path at run time
otherwise you will see the above error. I suspect that on the machine you
are running the executable that the Intel compiler is not installed or you
don't correctly source the ifortvars.sh file that sets up the environment
correctly for the Intel compilers.

The reason you don't see this with the -static flag is that here the
required libraries are actually included within the executable rather than
being linked to at runtime. Thus the location of the libraries need only be
known at compile time.

You should always use the -static flag when you can. Since all of the
libraries are linked in at runtime you will get a bigger executable in this
case and it may have a slightly higher memory residence size however with
modern machines this consideration is pretty much irrelevant. The advantage
of building a statically linked executable is that you can move it to or
from any machine with the same processor type and not have to worry about
whether that machine has the same version of the compiler installed, library
path correctly specified etc.

However, sometimes you will find that if you try to compile statically you
see a number of errors at link time. These are often a result of the fact
that the libraries you are trying to link against were only provided as
shared objects. In this case you cannot link them statically. This is often
the case with vendor supplied libraries where the licencing terms prevent
static linking. E.g. accelerated math libraries and some mpi libraries. In
this case you have to compile without the static flag and then make sure all
machines you will run on have the libraries installed in the same place, the
same version and have the environment setup to correctly define the
LD_LIBRARY_PATH and PATH variables.
 
> compile time - does
> this mean that the linking libraries have to be made
> available at run time?
> The concept doesn't make much sense to me right now.

Yes it does. On modern machines that have plenty of disk space and plenty of
memory there is little benefit in dynamically linking to libraries.
Technically you can upgrade the libraries without having to recompile
everything to take advantage of the new libraries but in reality this never
works and you would have to recompile anyway. The main issue with not using
static linking is as I covered above - a vendor provides only shared
objects.

> My question is therefore:
>
> 1. When should "static" be (or not be) used?

It should always be used if you can. I.e. if you find the compilation does
not work try recompiling without the static flag.

> 2. If I get round the compile-time problem using the "static"
> keyword, am I
> likely to run into problems later on during run-time?

If you use the static keyword you shoudl have no problems at run=time. If
you don't use the static keyword you could have problems at run time if your
environment variables are not correctly setup or you are running on another
machine that is missing the libraries or has different versions installed.

> 3. The shared object file that the error message refers to
> exists - why
> can't it be seen? (I have set
> "LD_LIBRARY_PATH=/opt/intel_fce_80/lib" and
> libcxaguard.so.5 does indeed reside there. I have also set
> symbolic links
> from this library to the main library in /usr/lib - to no avail.)

I'm not sure here. Technically the LD_LIBRARY_PATH should be observed
however you may want to add the path to your PATH variable to be sure.
Ideally you should not set this manually though, you should really source
the ifortvars.csh (or .sh) script provided with the intel compilers. Note
for parallel runs this needs to be done on every node.

> 4. The only way I can compile the parallel version (for lam
> mpi) without
> catastrophic error messages is by omitting the "static
> keyword". However, I

This is typical when compiling for parallel. One would have to build the
whole of lam statically in order to link against it statically. This is
do-able but not easily. Thus you should compile dynamically here and make
sure you have every node sourcing the ifortvars script. This means each node
needs to have the intel compilers installed.
 
I hope this helps.

All the best
Ross

/\
\/
|\oss Walker

| HPC Consultant and Staff Scientist |
| San Diego Supercomputer Center |
| Tel: +1 858 822 0854 | EMail:- ross_at_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.

-----------------------------------------------------------------------
The AMBER Mail Reflector
To post, send mail to amber_at_scripps.edu
To unsubscribe, send "unsubscribe amber" to majordomo_at_scripps.edu