On Thu, 2015-04-02 at 14:16 -0400, IBRAHIM M ABDELRADY wrote:
> Dear Amber developer:We are trying to install Amber14 on our system but we are
> having hard time doing that. I'm attaching the log file of the compiling to the
> e-mail.Here is the information about the compiler & MPI we used and the
> OS:Compiler: GCC 4.8.2, OpenMPI 1.8.1OS: Redhat 6.5We have followed the
> instructions outlined in
> http://jswails.wikidot.com/installing-amber14-and-ambertools14We started with
> serial with gnu compilation and finished off with the
> make test . Afterwards we tried the parallel with gnu compiler and then
> we received errors. We experienced errors when testing amber14 with serial code
> in particular the cpptraj executable had some errors. For some reason
> cpptraj was looking at libstdc++.so.6 in intel version when the
> compiler is set to gcc. It should be looking at
> <gcc-home-dir>/lib64/libstdc++.so.6 These errors are outlined in
> ambercompile.log file.
I'll just point out here that cpptraj itself does not look for anything.
foo.so is a shared library (.so == .Shared_Object). Unlike a static
archive (foo.a), the symbols from a shared library are not compiled into
the program you are building. One of the consequences here is that the
library then needs to be loaded at runtime so the required symbols are
defined. This task falls to the loader (ld)... we have no control over
that.
So what is really happening here is that the loader is loading libstdc
++.so (which is a link to libstdc++.so.6) in the Intel compiler library
directory. This happens because *something* in your environment or
system configuration is telling ld to do that. For instance, check the
value of the LD_LIBRARY_PATH and LIBRARY_PATH environment variables. I
suspect that they contain your Intel library folders. I would suggest
removing those.
>
> We noticed there was an error with ptraj executable when compiling in
> parallel, so we tried to compile ptraj manually
> $AMBERHOME/AmberTools/src/ptraj using make. The Makefile required
> pnetcdf.h in $AMBERHOME/amber14/include which was not present so we
> created the file and took the content from the web. We recompiled ptraj
> again and it failed again. When we tried to test SANDER it worked fine;
> however, SANDER.MPI did not work and gave errors.
>
> ../../../bin/cpptraj:
> /usr/global/intel/composer_xe/2015.0.090/vtune_amplifier_xe_2015.1.0.367959/lib64/libstdc++.so.6:
> version `GLIBCXX_3.4.15' not found (required by ../../../bin/cpptraj)
This makes it seem like your Intel compilers (which are *very* new)
don't work on this computer. They seem to require a GLIBC version that
is newer than what RHEL 6.5 ships with. So as long as ld is trying to
use Intel's libstdc++.so, cpptraj (or any other C++-based program, for
that matter) will not work.
> [snip]
> Here is the error produced when trying to run sander.MPI:MD Simulation
>
> job started on lionxv96.hpc.rcc.psu.edu at Thu Apr 2 13:23:34 EDT 2015
> sander.MPI: symbol lookup error: /usr/global/gcc-4.8.x/openmpi/1.8.1/lib/libmpi_mpifh.so.2: undefined symbol: mpi_fortran_weig
> hts_empty
This is evidence of either a broken OpenMPI installation or a borked
environment.
If I had to guess, I would say that your environment on this computer is
a bit corrupted (possibly from too much Google-induced monkey patching
to get stuff working -- I used to do that plenty).
Unfortunately, this kind of stuff can be a pain to debug remotely. I
often have to take 5 to 10 minutes just inspecting the environment
variables before I have an idea of what to try. Doing this process via
email could take a long time; I would suggest trying to find a Linux
expert locally and see if they can help you get this sorted.
HTH,
Jason
--
Jason M. Swails
BioMaPS,
Rutgers University
Postdoctoral Researcher
_______________________________________________
AMBER mailing list
AMBER.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber
Received on Thu Apr 02 2015 - 12:00:07 PDT
