Problem with dynamic linking to mkl_cfg_file

[PhilN]

We are using the Clearspeed accelerators, which dynamically link to MKL routines. We encounter a the error:

(our executable): symbol lookup error: /usr/local/intel/mkl/9.0/lib/em64t/libmkl_lapack32.so: undefined symbol: mkl_cfg_file

We have tried to give the Clearspeed libraries the proper environment variable with a list of .so files to search, including /usr/local/intel/mkl/libmkl_def.so, which seems to define mkl_cfg_file, according to nm. But no luck.

Do you have any idea why libmkl_lapack32.so wouldn't be satisfied with the mkl_cfg_file found in libmkl_def.so? Or any other suggestions?

Thanks.

P

[TimP]

mkl_lapack depends on the "core" MKL library (actually so named only in MKL 10). That would be the one from the same /em64t/ directory as the lapack. If you tried to use a 32-bit library, or one from an earlier MKL, that could account for missing references.

[PhilN]

So I have upgraded to MKL V10, and things seem better, but I still seem to be missing symbols. For example, at dynamic link time I get the message:

(my program): symbol lookup error: /opt/intel/mkl/10.0.1.014/lib/em64t/libmkl_intel_lp64.so: undefined symbol: mkl_lapack_sgeqrf

Yet, nm tells me that the symbol mkl_lapack_sgeqrf is defined in the Text section of the object libmkl_sequential.so, and I have the library libmkl_sequential.so in my list of .so's for the dynamic linker to search.

Any ideas?

Thanks.

P

[TimP]

It seems more likely that this should be an undefined symbol in the lp64 library, which should be defined in another library, e.g. mkl_core. As far as I know, the function of lp64 is to define entry points with 32-bit integer arguments, and the effect of sequential is to stub out OpenMP multithreading from MKL libraries. Hope I didn't mangle the working too much.

[Gabriel_R_]

I encountered the same problem on 32-bit linux when using a custom-built .SO file. I tracked it down to a bug in the makefile (/tools/builder/makefile), where the lapack routines are apparently not included with everything else:

ia32:
gcc -shared -Bdynamic $(func_list)
$(xerbla) $(mkl32_libpath)/libmkl_intel.a $(mkl32_libpath)/$(THREADING_LIB)
$(mkl32_libpath)/$(CORE_LIB) -L$(mkl32_libpath) -lguide -o $(name).so

should really have $(mkl32_libpath)/libmkl_lapack.a in there also, so the last line becomes

$(mkl32_libpath)/$(CORE_LIB) $(mkl32_libpath)/libmkl_lapack.a -L$(mkl32_libpath) -lguide -o $(name).so

when I rebuild my .SO file with this modified makefile, then everything works.

Cheers,
Gabriel

[TimP]

You may have been lucky. If you failed to link your lapack dependencies from mkl_core library the first time, it's because there are circular references, which can be resolved by surrounding the core and threading library pair with -Wl,--begin-group .... -Wl,--end-group as documented in the instructions for use of .a libraries. Otherwise, you can resolve it by repeating the libraries (usually 3 times) in correct order. If the sample script still shows the use of .a libraries to build a .so without showing the -group directives, that is a bug. Note that there was an update of MKL released today.

[Gennady_F_Intel]

Hello Phil,

As Tim recommended, for linking your application on Linux with MKL libraries you have to surround the core and treading libraries

-Wl,--begin-group .... -Wl,--end-group as documented in userguide manual ( see $MKLROOT/Doc/ folder ).

For example, for static linking lapack functionality for em64t, you can use the following example:

ifort -w test_lapack.f /opt/intel/mkl/10.0.1.014/lib/em64t/libmkl_intel_lp64.a -Wl,--start-group /opt/intel/mkl/10.0.1.014/lib/em64t/libmkl_intel_thread.a /opt/intel/mkl/10.0.1.014/lib/em64t/libmkl_core.a -Wl,--end-group -L/opt/intel/mkl/10.0.1.014/lib/em64t -lguide lib/libaux_em64t_intel.a -lpthread -o test.out

Gennady