topic Hi Evarist, in Intel® oneAPI Math Kernel Library

blas and lapack shared library

Nick_D_1 — Tue, 01 Mar 2016 17:49:48 GMT

Hi, I'm trying to port a Fortran library to Linux. This must be dynamic(shared) because its called from C# using DllImport (on Linux this will run under mono). There are dependencies on blas and lapack. Only static versions of libmkl_blas95 and libmkl_lapack95 are supplied by Intel (at least with this compiler version - composer XE 2015.5.223). As result, though the library builds happily and many functions can be used, other functions crash with unresolved symbols from lapack.

Since it seems possible, at least in C, to pull a static library into a shared library, I tried that, by in CMakeLists.txt putting TARGET_LINK_LIBRARIES("NameOfOurSharedLib" mkl_blas95_ilp64 mkl_lapack95_ilp64) . This get rejected with:

ld: /opt/intel/mkl/lib/intel64/libmkl_lapack95_ilp64.a(dgecon.o): relocation R_X86_64_32 against `__STRLITPACK_1' can not be used when making a shared object; recompile with -fPIC
/opt/intel/mkl/lib/intel64/libmkl_lapack95_ilp64.a: could not read symbols: Bad value

(Note, our shared library itself was compiled with -fPIC and doesn't have a problem until one tries to pull in these extra ones).

This page advises "Shared libraries must not be linked with archive libraries.", so maybe the above is a bad idea? I wondered instead about building shared versions of blas and lapack myself, as described here. I followed instructions on that page to add -fPic in the makefile but that still builds libmkl_lapack95_lp64.a, not a .so. Is there something else I need to change in that makefile?

Failing this, the only other thing I can think of is to pull in every .f90 file from lapack95 to my shared library, but that doesn't seem very nice.

Any suggestions?, Thanks, Nick

If you can use the netlib

TimP — Tue, 01 Mar 2016 19:08:44 GMT

If you can use the netlib source code for functions you need from those libraries, it might be best to build them yourself. You can't affect the code in a pre-built object by setting -fPIC.

Hi Nick,

Evarist_F_Intel — Wed, 02 Mar 2016 03:03:07 GMT

Hi Nick,

MKL provides the sources for these two libraries (blas95 and lapack95). Please find them in $MKLROOT/interfaces/{blas95,lapack95}.

You can add -fPIC option in the makefile and rebuild shared object libraries on your side.

Thanks Evarist and Tim for

Nick_D_1 — Wed, 02 Mar 2016 10:52:16 GMT

Thanks Evarist and Tim for replies. Adding the -fPIC option in the makefile wasn't enough on its own because it still tries to make an archive library. In the end I managed to interrupt the make operation and then do:

gcc -shared -o libmkl_lapack95_lp64.so lib95/lib/intel64/obj_lapack95_intel64_/*.o

to generate a shared library (and did similar for blas).

This makes shared libraries, but I'm now struggling to get CMake to link my local shared library to these (it keeps wanting to look at the archive libraries instead).

I might now try instead pulling all the .o s from blas and lapack into my local shared library. That's ugly but hopefully should work.

Suggestions welcome. :)

This makes shared libraries,

Evarist_F_Intel — Wed, 02 Mar 2016 11:02:37 GMT

This makes shared libraries, but I'm now struggling to get CMake to link my local shared library to these (it keeps wanting to look at the archive libraries instead).

Could you please clarify this statement? By default (if -lfoo specified) linker tries to use shared object libfoo.so. If it cannot find it, it tries to use libfoo.a. So, I would expect dynamic libraries to be used, unless -Wl,-Bstatic is used or the directory with the shared library is not specified.

BTW, creating *.so from *.a is absolutely ok (if objects are built with -fPIC). You might probably do something like this:

gcc -shared -olibmkl95.so \
  -Wl,--whole-arhive \
    libmkl_intel_blas95.a libmkl_intel_lapack95.a \
  -Wl,--no-whole-archive \
  -L$MKLROOT/lib/intel64 \
  -lmkl_intel_lp64 -lmkl_intel_thread -lmkl_core -liomp5 -lpthread -lm

Hi Evarist,

Nick_D_1 — Wed, 02 Mar 2016 14:24:09 GMT

Hi Evarist,

Thanks - your comment helped me fix CMake. I hadn't realised the linker looked for a .a if it couldn't find a .so. It was a case of messed up paths, so, problem of unresolved symbols now solved.

Would be nice if Intel would supply pre-built shared libraries for these though. I'm a little mystified why Intel would make shared libraries for everything else except blas and lapack, unless there is some underlying problem with having those as shared libraries in which case I might run into some further problems?

Regards, Nick