Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Trent_Hawkins
Beginner
109 Views

Unresolved reference to lapack95 subroutine

Jump to solution

I am sure I am making a very simple and obvious mistake in using lapack95, but I cannot figure it out at present.

Compiling and linking with MKL of the following sample code:

      program test_lapack
            use lapack95,only:ggev
            implicit none
            integer,parameter::x_=8
            integer,parameter::n =2
            complex(kind=x_)::a    (0:n-1,0:n-1)=reshape((/11._x_,12._x_,21._x_,22._x_/),(/2,2/))
            complex(kind=x_)::b    (0:n-1,0:n-1)=reshape((/ 1._x_, 0._x_, 0._x_, 1._x_/),(/2,2/))
            complex(kind=x_)::alpha(0:n-1)
            complex(kind=x_):: beta(0:n-1)
            call ggev(a,b,alpha,beta)
  end program test_lapack

with:

ifort -mkl=sequential test_lapack.F90

yields:

/tmp/ifortzuGiE1.o: In function `MAIN__':
test_lapack.F90:(.text+0x185): undefined reference to `zggev_f95_'

which means the program does find lapack95's ggev interface, but the zggev_F95 is still unresolved. I have checked that both the lapack95.F90 and all lapack95 routine implementations are in place, at /opt/intel/compilers_and_libraries_2016.3.210/linux/mkl/include and /opt/intel/compilers_and_libraries_2016.3.210/linux/mkl/interfaces/lapack95/source respectively. So it appears I am just missing on how to link the lapack95 implementation with its interface, or whatnot.

0 Kudos
1 Solution
mecej4
Black Belt
109 Views

The -mkl compiler flag does not pull in any Lapack95 or BLAS95 routines. That is why you have to specify the xx95 libraries explicitly.

Note that your command line in #4 specifies the static library for Lapack95. Most of the time, I prefer to use the shared library, so the flag for me would be -lmkl_lapack95_lp64 .

View solution in original post

5 Replies
mecej4
Black Belt
109 Views

You must specify that the mkl_lapack95 library is to be used at link time. This library wraps the F77 Lapack routines with F95 interfaces. For more details, consult the MKL Link Line Advisor.

Ying_H_Intel
Employee
109 Views

 

Yes, please refer to https://software.intel.com/en-us/articles/intel-mkl-link-line-advisor

for example, if 64bit application, you can try 

ifort  ${MKLROOT}/lib/intel64/libmkl_blas95_lp64 ${MKLROOT}/lib/intel64/libmkl_lapack95_lp64 -mkl=sequential test_lapack.F90

Best Regards,
Ying 

 

 

Trent_Hawkins
Beginner
109 Views

Thanks, I have been working my link line, using the link line advisor and modifying my own line accordingly. Thought ifort mkl performed super dynamic linking with no paths at all, but I was wrong. Well at least as the 95 interface is concerned. I could still use the ordinary F77 call but I wanted something more robust and reusable, especially when my real simulation (it is shown in this sample too) I use a globally adjustable precision. Thanks again for your help, both of you, and for the simple and demonstrative link line example.

EDIT

In particular, from link advisor:

ifort test_lapack.F90 ${MKLROOT}/lib/intel64_lin/libmkl_lapack95_lp64.a -lpthread -lm -ldl -I${MKLROOT}/include/intel64/lp64 -mkl=sequential

A simplified version (used with a well-setup ifort isntallation):

ifort test_lapack.F90 ${MKLROOT}/lib/intel64_lin/libmkl_lapack95_lp64.a -mkl=sequential

mecej4
Black Belt
110 Views

The -mkl compiler flag does not pull in any Lapack95 or BLAS95 routines. That is why you have to specify the xx95 libraries explicitly.

Note that your command line in #4 specifies the static library for Lapack95. Most of the time, I prefer to use the shared library, so the flag for me would be -lmkl_lapack95_lp64 .

View solution in original post

Trent_Hawkins
Beginner
109 Views

Awesome! Before posting this thread, I did try -lmkl_lapack95, which was getting me nowhere, and thus I posted it. I was missing the _lp64 suffix for integer specification! Many thanks again for the pointers, usage of the shared library (and in general as a much cross-platform command as possible) is my preference too.

Reply