Linux linking help with 10.0

[AndrewC]

Hi Linux gurus,

I link our executable against libmkl,so, libmkl_lapack.so with a link line

.... -L${MKLLIBS} -lmkl_lapack -lmkl

I do NOT specifically mention libmkl_intel.so libmkl_core.so 

When I do a "ldd" of our executable it shows the following

libmkl_lapack.so => ./libmkl_lapack.so (0xf57f0000)

/opt/intel/mkl/10.0.3.020/lib/32/libmkl_intel.so (0xf56b2000)

/opt/intel/mkl/10.0.3.020/lib/32/libmkl_intel_thread.so (0xf54b5000)

/opt/intel/mkl/10.0.3.020/lib/32/libmkl_core.so (0xf5451000)

Our executable will not run unless /opt/intel/mkl/10.0.3.020/lib/32/ is present and contains the libraries

Even if the librariesare present in our installation directory and LD_LIBRARY_PATH includes the installation directory, it will not run.

This is a change from 9.1

Can you suggest a workaround? I have already deployed some executables and was wondering if there is some LD magic variable to work around the problem.

[AndrewC]

Quoting - vasci_intel

Hi Linux gurus,

I link our executable against libmkl,so, libmkl_lapack.so with a link line

I added the-lmkl_intel -lmkl_intel_thread -lmkl_core to my link line. This made no difference to the problem.

I then set LD_DEBUG=libs and got the following output.

22671: find library=libmkl_lapack.so [0]; searching

22671: search path=/home/test/testexe (LD_LIBRARY_PATH)

22671: trying file=/home/test/testexe/libmkl_lapack.so

22671:

./test: error while loading shared libraries: /opt/intel/mkl/10.0.3.020/lib/32/libmkl_intel.so: cannot open shared object file:

I don't get it .... it is as iflibmkl_lapack.so "requires"libmkl_intel.so be in/opt/intel/mkl/10.0.3.020/lib/32 and ignores thelibmkl_intel.so present in theLD_LIBRARY_PATH.

[AndrewC]

I did another experiment.

- I built the ".so" examples into/opt/intel/mkl/10.0.3.020/examples/lapack/_results/intel_parallel_intel_guide_32_so

- I 'renamed' the/opt/intel/mkl/10.0.3.020/lib/32/

- as expected the examples no longer run with 'missing shared library'

- I copied all libmkl*.so files from/opt/intel/mkl/10.0.3.020/lib/32/into the same directory

- I set LD_LIBRARY_PATH to /opt/intel/mkl/10.0.3.020/examples/lapack/_results/intel_parallel_intel_guide_32_so

- I would expect this to work - but no luck running

objdump -p sgetrfx.out

shows....

Dynamic Section:

NEEDED /opt/intel/mkl/10.0.3.020/lib/32/libmkl_intel.so

NEEDED /opt/intel/mkl/10.0.3.020/lib/32/libmkl_intel_thread.so

NEEDED /opt/intel/mkl/10.0.3.020/lib/32/libmkl_lapack.so

NEEDED /opt/intel/mkl/10.0.3.020/lib/32/libmkl_core.so

NEEDED libguide.so

I am quite baffled -

[Andrey_Bespalov]

"I added the -lmkl_intel -lmkl_intel_thread -lmkl_core to my link line. This made no difference to the problem."

Please, remove -lmkl from the linking line.

.... -L${MKLLIBS} -lmkl_lapack -lmkl_intel -lmkl_intel_thread -lmkl_core

The libmkl.so is linking script that uses absolute paths. This behavior is changed in MKL 10.1.

[Ying_H_Intel]

Dear sir,

Could you please send us yourentiremakefile and exact compiler version?

1) Ithink, thisexperiment is not same the problem as you found with your application.

because, in fact, with the experiment, the link command is

>ifort -w source/sgetrfx.f /opt/intel/mkl/10.0.3.020/lib/32/libmkl_intel.so -Wl,--start-group /opt/intel/mkl/10.0.3.020/lib/32/libmkl_intel_thread.so /opt/intel/mkl/10.0.3.020/lib/32/libmkl_lapack.so /opt/intel/mkl/10.0.3.020/lib/32/libmkl_core.so -Wl,--end-group -L/opt/intel/mkl/10.0.3.020/lib/32 -lguide lib/libaux_ia32_intel.a -lpthread -o _results/intel_parallel_intel_guide_32_so/sgetrfx.out

Youcan see, itis linking the *.so withabsolute path, as the result, the pathwas embeded in exectutable file.

for example,

I copy the *.so into /opt/intel/mkl/10.0.3.020/examples/lapack/_results/intel_parallel_intel_guide_32_so

then enter command

[root@xpf-01 lapack]# ifort -w source/sgetrfx.f /opt/intel/mkl/10.0.3.020/examples/lapack/_results/intel_parallel_intel_guide_32_so/libmkl_intel.so -Wl,--start-group /opt/intel/mkl/10.0.3.020/examples/lapack/_results/intel_parallel_intel_guide_32_so/libmkl_intel_thread.so /opt/intel/mkl/10.0.3.020/examples/lapack/_results/intel_parallel_intel_guide_32_so/libmkl_lapack.so /opt/intel/mkl/10.0.3.020/examples/lapack/_results/intel_parallel_intel_guide_32_so/libmkl_core.so -Wl,--end-group -L/opt/intel/mkl/10.0.3.020/lib/32 -lguide lib/libaux_ia32_intel.a -lpthread -o _results/intel_parallel_intel_guide_32_so/mytest.out
[root@xpf-01 lapack]# objdump -p _results/intel_parallel_intel_guide_32_so/mytest.out

Dynamic Section:
NEEDED /opt/intel/mkl/10.0.3.020/examples/lapack/_results/intel_parallel_intel_guide_32_so/libmkl_intel.so
NEEDED /opt/intel/mkl/10.0.3.020/examples/lapack/_results/intel_parallel_intel_guide_32_so/libmkl_intel_thread.so
NEEDED /opt/intel/mkl/10.0.3.020/examples/lapack/_results/intel_parallel_intel_guide_32_so/libmkl_lapack.so
NEEDED /opt/intel/mkl/10.0.3.020/examples/lapack/_results/intel_parallel_intel_guide_32_so/libmkl_core.so

then it was sticked to /opt/intel/mkl/10.0.3.020/examples/lapack/_results/intel_parallel_intel_guide_32_so

It is expected behivours by compiler (or linker).

2) If we try to use general link command like

[root@xpf-01 lapack]# ifort -w source/sgetrfx.f -L/opt/intel/mkl/10.0.3.020/examples/lapack/_results/intel_parallel_intel_guide_32_so/

-lmkl_intel -lmkl_intel_thread -lmkl_lapack -lmkl_core -lguide -lpthread lib/libaux_ia32_intel.a

-o mytest2.out
[root@xpf-01 lapack]# objdump -p mytest2.out

Dynamic Section:
NEEDED libmkl_intel.so
NEEDED libmkl_intel_thread.so
NEEDED libmkl_lapack.so
NEEDED libmkl_core.so
NEEDED libguide.so
NEEDED libpthread.so.0
NEEDED libm.so.6
NEEDED libc.so.6

Then the problem is gone.

This way is similiar to your makefile.

So i guess, either you have explict pathlink in your makefile (Rpath will also stick tothe absolute path),

or you have -lmkl in your makefile, (whichhave such bug and can be removed in your command line), If you are using intel compiler and GNU ld.

Anyway, a entire test case will be helpful todiagnose the problem.

Regards,

Ying

[AndrewC]

Thanks for the diagnosis.....

I think we are agreed that the issue is caused by including -lmkl in my link line. If you do thatwith a simple example......

For example,
% ifort -w sgbrfsx.f -L/opt/intel/mkl/10.0.3.020/lib/32 -lmkl_lapack -lmkl -lmkl_intel -lmkl_core -lguide -lpthread libaux_ia32_intel.a -o sgbrfsx.out
% objdump -p sgbrfsx.out

sgbrfsx.out: file format elf32-i386

Program Header:
.....
Dynamic Section:
NEEDED libmkl_lapack.so
NEEDED /opt/intel/mkl/10.0.3.020/lib/32/libmkl_intel.so
NEEDED /opt/intel/mkl/10.0.3.020/lib/32/libmkl_intel_thread.so
NEEDED /opt/intel/mkl/10.0.3.020/lib/32/libmkl_core.so
NEEDED libmkl_intel.so

Take out the -lmkl from the link line and the problem goes away

% ifort -w sgbrfsx.f -L/opt/intel/mkl/10.0.3.020/lib/32 -lmkl_lapack -lmkl_intel -lmkl_core -lguide -lpthread libaux_ia32_intel.a -o sgbrfsx.out
% objdump -p sgbrfsx.out
sgbrfsx.out: file format elf32-i386

Program Header:
.....

Dynamic Section:
NEEDED libmkl_lapack.so
NEEDED libmkl_intel.so
NEEDED libmkl_intel_thread.so
NEEDED libmkl_core.so
NEEDED libguide.so

I believe that the documentation is actually correct and does not include -lmkl on the command line, but this is a very subtle trap for users upgrading from MKL 9 etc..


Andrew

[Ying_H_Intel]

Hi Andrew,

Good sample. Right, we will consider to add it in on-line documentation so that more users canavoid this.

Thanks

Ying