Hi,
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/iccvars_intel64.sh,
> called from
> /opt/intel/Compiler/11.1/069/bin/iccvars.sh
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 9.license2.osc.edu
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:
http://www.intel.com/software/products/compilers/docs/clin/main_cls/bldaps_cls/cppug_ccl/bldaps_manage_libs_cl.htm
> 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 ...
scott
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Thu Mar 04 2010 - 21:00:02 PST
