Re: [AMBER-Developers] more on ptraj compilation with Intel

From: Scott Brozell <>
Date: Thu, 4 Mar 2010 19:05:37 -0500


On Thu, Mar 04, 2010 at 05:25:30PM -0500, case wrote:
> I have some more information on ptraj compilation problems with intel compilers.
> (I assume these same issues are relevant for NAB as well, or other things
> that mix C and fortran objects.)
> 1. The startup scripts for Intel version 11 libraries set a LIBRARY_PATH
> variable, which appears to help(allow?) both icc and ifort to find each
> others' libraries. [I would be interested to hear of success/failures in
> compiling ptraj with intel version 11 compilers.]

That's not clear; at OSC ptraj builds fine (ignoring a gizzilion
warnings from the C++ish hacking in cluster.h)
with intel 10 and 11; there's no LIBRARY_PATH.

Mar 04 6:43:33pm 977$ ~/amber/intelamber11/src/ptraj ifort -V Intel(R) Fortran Compiler for applications running on Intel(R) 64, Version 10.0 Build 20070426 Package ID: l_fc_p_10.0.023
Mar 04 6:44:53pm 979$ ~/amber/intelamber11/src/ptraj rm ptraj ; mk ptraj AMBERBUILDFLAGS='-Wl,-M' | & g ifcor
icc -Wl,-M -o ptraj main.o rdparm.o dispatch.o help.o utility.o second.o io.o trajectory.o netcdf_ptraj.o parallel_ptraj.o evec.o torsion.o mask.o rms.o display.o interface.o energy.o experimental.o ptraj.o actions.o analyze.o thermo.o pubfft.o cluster.o clusterLib.o /nfs/10/srb/amber/intelamber11/lib/libpdb.a /nfs/10/srb/amber/intelamber11/lib/arpack.a /nfs/10/srb/amber/intelamber11/lib/lapack.a /nfs/10/srb/amber/intelamber11/lib/blas.a -lifport -lifcore -lsvml ../netcdf/lib/libnetcdf.a -lm
                              /usr/local/intel-10.0.023/lib/ (__itoq)
Mar 04 6:47:42pm 984$ ~/amber/intelamber11/src/ptraj setenv | g LIBRARY_PATH | gv LD_LIBRARY_PATH
Mar 04 6:47:44pm 985$ ~/amber/intelamber11/src/ptraj


> 2. When I downgraded to version 10 compilers, I didn't get rid of the
> LIBRARY_PATH variable, and it is not reset by the version 10 startup scripts.
> So, that was apparently why I appeared to have success with version 10 where
> others did not.

not clear as above.

> 3. Two fixes are easy to do manually, but not (yet) automagically:
> a. add the correct "-L" flag before the -lifprot -lifcore flags
> b. use FC rather than CC to link, and add the -nofor-main flag to
> the link command.
> c. The user could also manually set the LIBRARY_PATH environment
> variable (really the same as using the "-L" flag in a.

still working on getting the magic...

> 4. [Aside: does anyone know how to turn on verbosity in the link step, so
> that we can find out what icc is doing with the "-lifport -lifcore"
> flags? It is not complaining that they are not found, so it must be
> resolving the name some, but not finding a suitable library. It's not
> clear that knowing this would help us solve the underlying problem, but
> it would still be nice to feel that I understood what is going on.

as above
This use to be in our configure with its verbose flag...a minor casualty.

> 5. I think the configure script could fairly easily be made to do the
> following:
> a. determine if we have an old version of the intel compilers
> b. parse `which ifort` and `which icc` to get their absolute paths;
> strip off the trailing "bin/ifort" and replace it with "lib".
> c. use the result to add the correct "-L" flag to the flibs_arch
> variable for intel (line 426 of configure).
> I someone has time to try this out, that would be great.

low tech, but should work;
i prefer to investigate higher tech 1st.


AMBER-Developers mailing list
Received on Thu Mar 04 2010 - 16:30:04 PST
Custom Search