CODEWITHSUNDEEP
c++pythonboostfortranintel-mkl
user1883017
user1883017

Reputation:

Linking Intel's MKL within Python-C++-C-Fortran 2003 program

I am trying to link a program which nature is pretty complicated:

During the runtime I get the following text

MKL FATAL ERROR: Cannot load neither libmkl_avx.so nor libmkl_def.so

after which program stops.

I have checked that both libmkl_avx.so and libmkl_def.so are in $LD_LIBRARY_PATH

The final linking is done via:

g++ -g3 -shared -Wl,-soname,libFrrBoost_rt.so interfejs.o t83.o gen_random2.o 
-L/opt/intel/composerxe/mkl/lib/intel64 -lpython2.7 -lifport -lifcore -lboost_python     
-Wl,--start-group -lmkl_sequential -lmkl_intel_lp64 -lmkl_core  -Wl,--end-group 
-o libFrrBoost_rt.so

libFrrBoost is the module that is linked, then

running python t83.py (in particular linker does not complain when preparing the binary file) which imports the module libFrrBoost causes the error.

Tried to google. All the info I found was connected with "usual programs" written in C/Fortran and simply including Intel's MKL. I am able to run this sort of programs with no problem. I think the MKL part of the linking line in the Makefile is equivalent in both cases, but there must be somewhere a hidden mystery. The problem was usually bad linking - which I do not see applicable (the libraries are exactly as in Intel's manual - Interface, Threading and computational libraries are pretty standard)

Used compilers:

ifort 12.1.0, icpc 12.1.0, python Python 2.7.1, icc 12.1.0 (the small C snippet also calls MKL, but)

EDIT (due to a comment of Hirsto Iliev)

I have run the strace in this way: strace python t83.py; The result is (after grepping libmkl:

open("/opt/intel/composer_xe_2011_sp1.7.256/mkl/lib/intel64/libmkl_avx.so", O_RDONLY) = 3
open("/usr/bin/libmkl_avx.so", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/opt/slurm-2.2.5/lib/libmkl_avx.so", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/opt/intel/composer_xe_2011_sp1.7.256/compiler/lib/intel64/libmkl_avx.so", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/opt/intel/composer_xe_2011_sp1.7.256/debugger/lib/intel64/libmkl_avx.so", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/opt/intel/composer_xe_2011_sp1.7.256/mkl/lib/intel64/libmkl_avx.so", O_RDONLY) = 3

I understand that the specification for open is as in here an, in particular, as 3,4 are positive and indicate that open has found a file and assigned it file discriptors. I have verified that the file does exist in that place.

also this is "good" Intel compiler directory as:

czeslaw@stefan:~/prog/FoCpy3 $ which ifort
/opt/intel/composer_xe_2011_sp1.7.256/bin/intel64/ifort

So the version is the same - aparently it is not a version issue.

Everything is the same for libmkl_def.so.

DISCLAIMER: Although I may sound confident in what I write I am not. Every sentence should begin with "If I am not mistaken".

Upvotes: 3

Views: 4983

Answers (2)

Misha
Misha

Reputation: 572

For me solution proposed on the intel site works well

export LD_PRELOAD=/opt/intel/mkl/lib/intel64/libmkl_core.so:/opt/intel/mkl/lib/intel64/libmkl_sequential.so

It seem to be some kind of bug.

Upvotes: 12

user1883017
user1883017

Reputation:

It seems the solution is to link with -lmkl_rt instead of -lmkl_sequential -lmkl_intel_lp64 -lmkl_core. I do not see why one should give advantageous over te other. I am confused but that works (so far).

edit Intel people claim this was MKL library bug.

Upvotes: 6

Related Questions