Dynamic linking error with mkl and ifc 9.1 (em64t)

[jtime23]

Okay fixed that last problem, em64t install now works.

New problem: I have a dynamic linking problem on a code with a couple of lapack calls (dgetrf,dgetrs). This is on a dual core Pentium 830 using the em64t compiler and libs (fedora core5).

First note that if I compile with -static option, everything works perfectly and program runs correctly. If I allow default compile with dynamic, here's what happens.

Program compiles okay with

ifort myprog.f -L /opt/intel/mkl/8.1/lib/em64t -lmkl_lapack -lmkl_em64t -lguide -lpthread

On execution I get:

error while loading shared libraries:
/opt/intel/fce/9.1.032/lib/libguide.so: cannot restore segment prot after reloc: Permission denied

Note that I have both mkl and fc libs in LD path; i.e.
$echo LD_LIBRARY_PATH

/opt/intel/fce/9.1.032/lib:/opt/intel/mkl/8.1/lib/em64t


Next I tried throwing in -lm library at end of compile statement. Then I get

error while loading shared libraries: /opt/intel/fce/9.1.032/lib/libirc.so: cannot restore segment prot after reloc: Permission denied

I know it's finding the dirs in LD_LIBRARY_PATH okay, because if I set that variable to null, I get

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

ANY THOUGHTS? jon

Message Edited by jtime23@aol.com on 05-22-200607:23 PM

Message Edited by jtime23@aol.com on 05-22-200607:26 PM

[micahe]

See this post.

[TimP]

It's not good to set up a situation where you have libguide visible from both the MKL library and the ifort library, and may see one at link time and the other at run time. The reason for providing libguide with MKL is to take care of the case where no Intel compiler library is available, or the Intel compiler library is an older version than the MKL. Neither of those cases is present here. The advice which should be present somewhere in the MKL docs is, if you leave the near duplicate libraries in your MKL installation, don't set the -L path to point to it. Instead, specify the full paths of the MKL and lapack libraries, and allow ifort to provide its version of the libguide. As you are using static MKL libraries, you don't need MKL to appear in LD_LIBRARY_PATH at run time.

[jtime23]

Micah: thanks for that info. I prefer not use magic bullets like that until I fully understand their mechanism.

Tim: thanks, that explains part of it, but still am a bit confused. I did check and the libguide.so files are identical - but your point is well taken and this possibility should be avoided as you suggested.

I removed the mkl from the ld path and also for good measure removed the .so libs from the mkl dir.

Now when I rerun, I get thesame type of problem,but with libirc.solibrary which is not in mkl at all and which I do not explicitly link

error while loading shared libraries: /opt/intel/fce/9.1.032/lib/libirc.so: cannot restore segment prot after reloc: Permission denied

On further reading at Intel, it appears libirc is one which one needs to be careful with in multithreaded applications.

Finally, when I omit -libm library (I usually don't need those extra GNU math functions), it all works fine - i.e the libirc ref and complaint goes away. I am not quite sure how libm and libirc are interacting, but things are working and I can explore that point later.

Thanks, jon