static linking with MKL

[Dan4]

Dear all,

I am using Intel C++ Compiler 11.1 and MKL sipped with the compiler suite on Linux. My code works fine, but I can not link the MKL libraries in static way so the code will be portable without need to have MKL library file on other systems. I use following options:

MKL = -Wl, --start-group "/home/dan/intel/Compiler/11.1/073/mkl/lib/em64t"/libmkl_intel_lp64.a "/home/dan/intel/Compiler/11.1/073/mkl/lib/em64t"/libmkl_intel_thread.a "/home/dan/intel/Compiler/11.1/073/mkl/lib/em64t"/libmkl_core.a -Wl, --end-group -openmp -lpthread -lguide -static-intel -lmkl_solver_lp64 -DMKL_Complex16="std::complex"

but the linker fails with this error message:

__tmp_ztrtri.f:(.text+0x37b): undefined reference to `mkl_blas_ztrmm'
__tmp_ztrtri.f:(.text+0x6a5): undefined reference to `mkl_blas_ztrmm'
/home/dan/intel/Compiler/11.1/073/mkl/lib/em64t/libmkl_core.a(dtrtri.o): In function `mkl_lapack_dtrtri':
__tmp_dtrtri.f:(.text+0x383): undefined reference to `mkl_blas_dtrmm'
__tmp_dtrtri.f:(.text+0x697): undefined reference to `mkl_blas_dtrmm'

I have googled about it but didn't find something different. Have you ever had same experience that would help?

Thanks,

D.

[barragan_villanueva_]

Hi,

You need to
1) delete -lguide (because you already used -openmp)
2) move library -lmkl_solver_lp64 before all MKL libraries if you need it or delete

[Dan4]

Hi Victor and thanks for your help. I did exactly what you mentioned but it didn't help. I can successfully compiler the code with exactly same options but using dynamic libraries (.so instead of .a) without any error.

D.

[barragan_villanueva_]

OK
Could you please create small testcase to reproduce the problem?
What MKL version do you use?

[Dan4]

Hi,

I queried the version of MKL and it is

Intel Math Kernel Library Version 10.2.6 Product Build 20100728 for Intel 64 architecture applications

About the smaller test case, I guess it would be same, because even with few lines of code, the compiling options would be same so that won't help. Am I right?

Thanks,

D.

[barragan_villanueva_]

Quoting danltu.se

About the smaller test case, I guess it would be same, because even with few lines of code, the compiling options would be same so that won't help

Well, could you please send it with complete compile and link line?

[Dan4]

Sure, the compilation is done as:

/home/dan/intel/Compiler/11.1/073/bin/intel64/icpc -DHAVE_CONFIG_H -I. -I/home/dan/intel/Compiler/11.1/073/mkl/include -I.. -I../include -DNOGMM_VERIFY -DUSE_OPENMP -O0 -ipo0 -fp-model precise -parallel -openmp -vec-report -par-report -openmp-report -DMKL_VML_MIXED -static-intel -fasm-blocks -use-msasm -MT solver.o -MD -MP -MF .deps/solver.Tpo -c -o solver.o solver.cpp


The above line compiles only one file "solver.cpp" but all source files are compiled with same options, and they are linked as:


/home/dan/intel/Compiler/11.1/073/bin/intel64/icpc -O0 -ipo0 -fp-model precise -parallel -openmp -vec-report -par-report -openmp-report -DMKL_VML_MIXED -static-intel -fasm-blocks -use-msasm -Wl, --start-group "/home/dan/intel/Compiler/11.1/073/mkl/lib/em64t"/libmkl_intel_lp64.a "/home/dan/intel/Compiler/11.1/073/mkl/lib/em64t"/libmkl_intel_thread.a "/home/dan/intel/Compiler/11.1/073/mkl/lib/em64t"/libmkl_core.a -Wl, --end-group -openmp -lpthread -static-intel -DMKL_Complex16="std::complex" -o peec lproutines.o computation.o comp_wrapper.o util.o functions.o model.o parser.o solver.o peec.o integrationAPI.o subdivision.o matlabPlotter.o vtkPlotter.o incidentField.o FieldCalculator.o -lstdc++ -L/home/dan/intel/Compiler/11.1/073/mkl/lib/em64t -lguide -lpthread -lcxaguard -limf -lirc

Thanks for your help,

D.

[TimP]

gnu ld places ordering requirements. You would need to put your .o files ahead of the MKL libraries, so that the linker knows which MKL functions are required when reading the .a files. Also, as mentioned in an earlier answer, you must remove -lguide, as the -parallel and -openmp options in your compiler imply -liomp5.

[Dan4]

Hi,

Thanks for your help. The problem with MKL static linking isn actually solved! I should have removed the space between "-Wl," and "--start-group"! Now it works fine. The new problem is that when I copy my executable into a virgin machine, it still complains:

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

I tried to link static "libguide.a" and however it was linked without any problem, but the problem still exists. Is there any way to link everything in a static way or there are some shared libraries that should be shipped anyway?

Thanks,

D.

[Dan4]

Hi,

Actually I solved the previous problem by static link to "libguide.a" but now it needs:

error while loading shared libraries: libcxaguard.so.5: cannot open shared object file: No such file or directory

I used static link to "libcxaguard.a" but it didn't fix the problem. Is there any remedy for this?

I am wondering if there is any way to tell compiler (or linker) to use static link whenever a dynamic library is needed by giving the path of course. Here by just testing one by one is a very tedious task.

Thanks,

D.

[barragan_villanueva_ · Accepted solution]

Hi,

If you use option -openmp then libguide will not be required. So, it's strange that you had problem with"libguide.a" and "libcxaguard.a".

As to your question:
any way to tell compiler (or linker) to use static link whenever a dynamic library is needed
- please clarify what you mean.

Here areoptions to tell compiler to use static or dynamic libraries:
On Linux can be used options (pair of brackets) -Bstatic .... -Bdynamic when -lare used inside there together with -L
Also, you can use -static to use only static linking for all libraries.

[Dan4]

Hi,

You were right. I removed "libguide.a" and "libcxaguard.a" and used "-openmp" and it is solved now. So practically no further libraries are needed. I recently read in MKL release notes I think, that it is recommended to use dynamic libraries. I don't know why, so I am thinking to either compile with static linking and also keep the option to ship redistributable libraries by dynamic linking.

Anyway, thank you so much all for your valuable comments and help.

Regards,

Danesh

[TimP]

Using dynamic libraries avoids some problems you could get into with link order on static libraries. You can download a redistributable library package should you choose to go that way.

[Hans_P_Intel]

Since this article may still appear when searching for static linkage, I wanted to point people to the Intel MKL Link Line Advisor - this should be the first place when linking with Intel MKL libraries. For custom static linkage (e.g., in case of a lagacy build system), the following article might be helpful as well.