[Wien] 64 Bit x86_64 compile
Atwood, Robert C
r.atwood at imperial.ac.uk
Wed Aug 3 12:43:35 CEST 2005
Brian,
Yes I think I mentioned in a previous post, but to clarify:
-lmkl_lapack It builds (static lapack I guess)
-lmkl_lapack64 It builds
-lmkl_lapack32 It does not build
no mkl_lapack* It does not build
-lvml also needed to be explicitly include which appears to differ from what you originally posted for your system
I determined initially that the missing calls were lapack by using objdump on the library files .
Is there any reason to prefer static (.a) or dynamic (.so) ? On the cluster would .a libraries save any significant amount of network reads when the library is installed on an NFS mounted volume? I would guess it is not that significant , I assume it reads the library once per execution; but I am not actually familiar with the details of shared library usage so I could be wrong.
Here is the contents of the current OPTIONS file after a successful compilation. The -v flag is :
current:FOPT:-FR -mp1 -w -prec_div -pc80 -pad -ip -DINTEL_VML
current:FPOPT:-FR -mp1 -w -prec_div -pc80 -pad -ip -DINTEL_VML
current:LDFLAGS:-pthread
current:DPARALLEL:'-DParallel'
current:R_LIBS:-L/usr/local/Cluster-Apps/intel/mkl/7.21.003/lib/em64t -lmkl -lmkl_lapack64 -lvml -v
current:RP_LIBS:-L /usr/local/SCALAPACK -L /usr/local/BLACS/LIB -lpblas -lredist -ltools -lscalapack -lfblacs -lblacs -lmpi
Of course this reflects the non-standard installation location for the intel mkl libraries
________________________________
From: wien-bounces at zeus.theochem.tuwien.ac.at on behalf of Brian R Smith
Sent: Tue 02/08/2005 20:29
To: A Mailing list for WIEN2k users
Subject: Re: [Wien] 64 Bit x86_64 compile
Robert,
> ******** some error messages if -L [path-to-mkl]/em64t -lmkl
> -lmkl_lapack32 -lvml is used ************
> bandv1.o(.text+0xbcf): In function `bandv1_':
> : undefined reference to `dlarnv_'
> dgeqrl.o(.text+0x179): In function `dgeqrl_':
> : undefined reference to `dlarf_'
> (lots more)
Those "undefined references" are Lapack calls. Have you tried
-L[path-to-mkl]/em64t -lmkl -lmkl_lapack -lvml
Not specifying 32 or 64?
Also, what options did you use to get it to build correctly (unless i
missed it in a previous post)?
-Brian
On Tue, 2005-08-02 at 19:26 +0100, Atwood, Robert C wrote:
> 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.
>
> 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 :
>
> set
> root /usr/local/Cluster-Apps/intel/fce/8.1-026/
> append-path PATH $root/bin
> append-path MANPATH $root/man
> append-path LD_LIBRARY_PATH $root/lib
>
> Anyway it is compiled now so it's a moot point.
>
> ******** some error messages if -L [path-to-mkl]/em64t -lmkl
> -lmkl_lapack32 -lvml is used ************
> bandv1.o(.text+0xbcf): In function `bandv1_':
> : undefined reference to `dlarnv_'
> dgeqrl.o(.text+0x179): In function `dgeqrl_':
> : undefined reference to `dlarf_'
> (lots more)
>
> ******** some error messages if -L [path-to-mkl]/em64t -lmkl -lvml is
> used ************
> bandv1.o(.text+0xbcf): In function `bandv1_':
> : undefined reference to `dlarnv_'
> dgeqrl.o(.text+0x179): In function `dgeqrl_':
> : undefined reference to `dlarf_'
> dgeqrl.o(.text+0x307): In function `dgeqrl_':
>
>
>
> > > > Robert,
> > > >
> > > > > Or, should it use -lmkl_lapack32 ?
> > > >
> > > > I haven't built with Intel on the EM64T chips, so I don't know
> if the
> > > > compiler defaults to 64bit or if you have to specify it
> explicitly. I
> > > > would do a 'file' on one of the .o object files generated during
> the
> > > > install. It will tell you if it's 32bit or 64bit. Actually, I
> don't
> > > > ever recall actually having to use -lmkl_lapack* after passing
> -lmkl to
> > > > the linker. On 32bit systems with 7.x series MKL, -lmkl_lapack
> is
> > > > included implicitly with -lmkl.
>
> _______________________________________________
> Wien mailing list
> Wien at zeus.theochem.tuwien.ac.at
> http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
--
--
Brian R. Smith
HPC Systems Administrator
Research Computing Core Facility, USF
Phone: 1(813)974-1467 Cell: 1(813)230-3441
Address: 4202 E Fowler Ave LIB 613
Tampa, FL 33620
Web: http://rccf.acomp.usf.edu
_______________________________________________
Wien mailing list
Wien at zeus.theochem.tuwien.ac.at
http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/ms-tnef
Size: 9597 bytes
Desc: not available
Url : http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20050803/1e59ed7b/attachment.bin
More information about the Wien
mailing list