Hi,
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 opt-login04.osc.edu 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 opt-login04.osc.edu 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/libifcore.so.5 (__itoq)
Mar 04 6:47:42pm opt-login04.osc.edu 984$ ~/amber/intelamber11/src/ptraj setenv | g LIBRARY_PATH | gv LD_LIBRARY_PATH
Mar 04 6:47:44pm opt-login04.osc.edu 985$ ~/amber/intelamber11/src/ptraj
intel-compilers-11.1.056
...
> 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
mk ptraj AMBERBUILDFLAGS='-Wl,-M'
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.
scott
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Thu Mar 04 2010 - 16:30:04 PST
