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

From: Scott Brozell <>
Date: Thu, 4 Mar 2010 23:32:37 -0500


On Thu, Mar 04, 2010 at 11:16:56PM -0500, case wrote:
> On Thu, Mar 04, 2010, Scott Brozell wrote:
> >
> > 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.
> Are you sure? Are you not running a script like
> /opt/intel/Compiler/11.1/069/bin/intel64/,
> called from
> /opt/intel/Compiler/11.1/069/bin/

Yes. Definitely not; at OSC software access is controlled by modules;
users load or unload modules; and for intel this is it:
module-whatis "loads the Intel C/C++/F95 compilers"
# for Tcl script use only
set version 11.1.056
set intelinst /usr/local/intel-$version
prepend-path LM_LICENSE_FILE
prepend-path MANPATH $intelinst/man
prepend-path PATH $intelinst/bin/intel64
append-path LD_LIBRARY_PATH $intelinst/lib/intel64
set-alias efc ifort
set-alias ecc icc

> paths may be different, but should be recognizable.
> These scripts (plus ifort and mkl analogs) definitely set the LIBRARY_PATH
> variable, at least at Rutgers. [version 10 scripts don't set this variable.]
> Actually, it looks like maybe both C and Fortran libraries are in
> /usr/local/intel-10.0.023/lib at OSC, which is different than the layout
> for "most" installations. So maybe this is why things work at OSC (version
> 10) but fail at other locations.

Yes, this is the underlying issue, and the purpose of LIBRARY_PATH
is to specify link time paths:

> I have to retire now, and won't be able to work on this tomorrow. Thanks for
> the work done so far.

rock a bye baby; go to sleep; go to sleep ...

AMBER-Developers mailing list
Received on Thu Mar 04 2010 - 21:00:02 PST
Custom Search