MKL/Lapack compilation problem

MKL/Lapack compilation problem

Sorry if this is a really simple question but I'm pulling my hair out with this one! I've just installed the MKL and wrote a couple of test programs. The first one just uses BLAS and compiles and runs fine with:

ifc -o test_blas -L/opt/intel/mkl/lib/32/ -lmkl_p3 -lguide test_blas.f90

However, a similar program using a lapack routine doesn' compile and:

ifc -o test_lapack -L/opt/intel/mkl/lib/32/ -lmkl_lapack -lmkl_p3 -lguide test_lapack.f90

returns an error:

undefined reference to 'sgesv_'

What is going on quite? When I 'ar t libmkl_lapack.a | grep sgesv' I get


Have I missed something really obvious? I don't see how the BLAS can work fine and this cause problems. Any pointers would be much appreciated.


8 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

Yes, seems odd. Where does the reference come from? Perhaps try linking with the mkl shared libraries?

OK, please excuse my ignorance but how do I link with the shared libraries as opposed to the static?

The reference comes from my program which is calling sgesv as a test.

Well, now if I compile with:

ifc -o test_lapack -L/opt/intel/mkl/lib/32/ -lmkl_lapack32 -lmkl_p3 -lguide test_lapack.f90

I can compile fine. When it comes to running the executable I get:

error while loading shared libraries: cannot open shared object file: No such file or directory

Which is strange because I've quoted -lmkl_lapack32 and exists! Also, my LD_LIBRARY_PATH is set correctly.

Thanks for any further pointers.

I'm not sure if this is a bug or a feature:

You have linked test_lapack with -lmkl_lapack32 but a
'ldd test_lapack' searches for ''.

A quick and dirty solution, link to and it works.

Cheers, mr-todd.

Thanks a bunch! Quick and dirty and it does work.

Now, to help with future problems, could you explain _why_ it works?!

When you say that your LD_LIBRARY_PATH is set correctly, do you mean that the MKL library path is included? I don't have the latest version of MKL, but mine doesn't set this up automatically. When I have set up the compiler environment variables, the compiler library path is added to LD_LIBRARY_PATH, but the MKL library path is still not included. If you are implying that these things should be set up automatically, I agree, but apparently that is not the case. It is a traditional problem with g77 as well; the libraries aren't necessarily picked up from the same software installation you used to build.

I believe that only the older versions of MKL support static linking. If you have a preferred solution, such as having the mkl libraries become sym-linked automatically into the ifc library path, or the standard paths according to LSB, you might consider filing a report on Give your version details and the explanation of how your executable can't find the .so, without your taking additional steps beyond the basic installation.

Yes, I set LD_LIBRARY_PATH explicitly in my shell .bashrc script - echo $LD_LIBRARY_PATH gives:


My IFC is version 7.0 and MKL version 5.2.

Is this not an issue with the way I am calling the compiler/or exactly which libraries I am using given that I can compile and link and run sucessfully with the MKL BLAS library, with exactly the same compiler options/environment (apart from obviously the specified libraries)?

Feeling very confused!

OK, phrasing this another way, I've posted the 2 code snippets at:

I can compile and run test_blas.f90 fine. Please can someone let me know what command line options I need to use to get test_lapack.f90 to compile and run.


Leave a Comment

Please sign in to add a comment. Not a member? Join today