[Wien] 64 Bit x86_64 compile

[Brian R Smith]

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