<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META NAME="Generator" CONTENT="MS Exchange Server version 6.5.7226.0">
<TITLE>Re: [Wien] compiler pathscale</TITLE>
</HEAD>
<BODY>
<DIV id=idOWAReplyText66660 dir=ltr>
<DIV dir=ltr><FONT face=Arial color=#000000 size=2><FONT
face="Times New Roman">In the intel/mkl/7.21.003/lib/em64t directory there are
libraries called libmkl_lapack32.so and libmkl_lapack64.so , both of which
'file' as 64 bit objects. I dont' know what the difference is, but they
differ. I was wondering if this is known to make any difference for the
wien2k code ... but actually it doesn't compile with -lmkl_lapack32 so
that answers my question. There is also a libmkl_lapack.a (no 32 or 64) that
also works. I suppose one must consult the Intel people to
find out what the purpose of the 32 suffix library compiled in 64 bits is
supposed to be for.</FONT></FONT></DIV>
<DIV dir=ltr><FONT size=2></FONT> </DIV>
<DIV dir=ltr><FONT size=2>LD_LIBRARY_PATH not signifying at compile time -- I
agree, but where does the build find the location
/usr/local/Cluster-Apps/intel/fce/8.1-026//lib/ for the Intel libraraies? I did
not enter this into the siteconfig and yet it is found correctly during build,
even the erroneous double-slash as in the environment variable is
replicated. The 'environment module' only alters PATH, MANPATH and
LD_LIBRARY_PATH :</FONT></DIV>
<DIV dir=ltr><FONT size=2></FONT> </DIV>
<DIV dir=ltr><FONT
size=2>set
root
/usr/local/Cluster-Apps/intel/fce/8.1-026/<BR>append-path
PATH
$root/bin<BR>append-path
MANPATH
$root/man<BR>append-path
LD_LIBRARY_PATH $root/lib<BR></FONT></DIV>
<DIV dir=ltr><FONT size=2>Anyway it is compiled now so it's a moot point.
</DIV></FONT>
<DIV dir=ltr> </DIV>
<DIV dir=ltr><FONT size=2>******** some error messages if -L
[path-to-mkl]/em64t -lmkl -lmkl_lapack32 -lvml is used
************</FONT></DIV>
<DIV dir=ltr><FONT size=2>bandv1.o(.text+0xbcf): In function `bandv1_':<BR>:
undefined reference to `dlarnv_'<BR>dgeqrl.o(.text+0x179): In function
`dgeqrl_':<BR>: undefined reference to `dlarf_'</FONT></DIV>
<DIV dir=ltr><FONT size=2>(lots more)</FONT></DIV>
<DIV dir=ltr><FONT size=2></FONT> </DIV>
<DIV dir=ltr><FONT size=2>******** some error messages if -L
[path-to-mkl]/em64t -lmkl -lvml is used ************</FONT></DIV>
<DIV dir=ltr>bandv1.o(.text+0xbcf): In function `bandv1_':<BR>: undefined
reference to `dlarnv_'<BR>dgeqrl.o(.text+0x179): In function `dgeqrl_':<BR>:
undefined reference to `dlarf_'<BR>dgeqrl.o(.text+0x307): In function
`dgeqrl_':<BR></DIV>
<DIV dir=ltr><FONT size=2><BR> </DIV></FONT>
<DIV dir=ltr><FONT face=Arial color=#000000 size=2><FONT
face="Times New Roman">> > > Robert,<BR>> > ><BR>> >
> > Or, should it use -lmkl_lapack32 ?<BR>> > ><BR>> > >
I haven't built with Intel on the EM64T chips, so I don't know if the<BR>>
> > compiler defaults to 64bit or if you have to specify it
explicitly. I<BR>> > > would do a 'file' on one of the .o object
files generated during the<BR>> > > install. It will tell you if
it's 32bit or 64bit. Actually, I don't<BR>> > > ever recall
actually having to use -lmkl_lapack* after passing -lmkl to<BR>> > >
the linker. On 32bit systems with 7.x series MKL, -lmkl_lapack is<BR>>
> > included implicitly with
-lmkl.</FONT><BR></DIV></FONT></DIV>
</BODY>
</HTML>