Linking OpenMP dynamically with static-intel

[tried100times]

Hi all,

Due to a problem with libirc (described in a seperate thread) I am using -static-intel in an attempt to build Matlab mex files.

Now by using static-intel and manually specifying the libifcoremt_pic.a library I am able to build the excellent Matlab F95 interface.

Next, I am trying to compile some of my own functions which use openmp. However there don't seem to link dynamically despite adding the option -openmp-link dynamic, and static linking fails due to -fPIC (required by matlab):

Am I missing anything or have I made a mistake? From the man page I understand it should be fine to have openmp-link dynamic together with static-intel...

[bash]-> /opt/intel/bin/ifort -c  -I/usr/local/MATLAB/R2010b/extern/include -I/usr/local/MATLAB/R2010b/simulink/include -xhost -fexceptions -openmp -openmp-link dynamic -fpp -fPIC -static-intel -nofixed -I/home/robince/src/MatlabAPI_20091219  -O2  "pdist_info.f"

-> /opt/intel/bin/ifort -O2 -xhost -fPIC -static-intel -openmp -openmp-link dynamic -shared -Wl,--version-script,/usr/local/MATLAB/R2010b/extern/lib/glnxa64/fexport.map -Wl,--no-undefined -o  "pdist_info.mexa64"  pdist_info.o  "finfo.o"  "fmisim.o"  "/home/robince/src/MatlabAPI_20091219/MatlabAPImex.o"  "/home/robince/src/MatlabAPI_20091219/MatlabAPImx.o"  /opt/acml4.4.0/gfortran64/lib/libacml_mv.a /opt/intel/lib/intel64/libifcoremt_pic.a -Wl,-rpath-link,/usr/local/MATLAB/R2010b/bin/glnxa64 -L/usr/local/MATLAB/R2010b/bin/glnxa64 -lmx -lmex -lmat -L/opt/intel/lib/intel64 -lm

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

    mex: link of ' "pdist_info.mexa64"' failed.

??? Error using ==> mex at 208
Unable to complete successfully.
 [/bash]

[tried100times]

As an update - manually adding -liomp5 lets it build successfully, but the -openmp-link option seems to have no effect then, always linking dynamically whichever is selected.

This is fine for my purposes but means I'm obviously misunderstanding something about how the options are supposed to work. I would have thought -openmp-link dynamic should have automatically added iomp5? (Without adding -liomp5 manually, the option again has no effect and it always tries to link omp statically).

[TimP]

The docs for the current ifort list openmp-link as a Deprecated Option with "No replacement." As far as I know, it's possible to replace -liomp5 by the full path name of libiomp5.a, in the final link stage of your build. Not knowing fully why the docs recommend so strongly against this, I could mention some of the down sides:
If you link static OpenMP lib at an early stage of the build (e.g. when building a dynamic library) and perform final link later, you may expect run-time conflicts.
You will lose some useful OpenMP thread profiling capabilities such as the ability to set LD_PRELOAD=. I've heard that this also is a deprecated facility, but so far, it continues to be useful.
I would not recommend choosing an old version of ifort simply because it supports openmp-link option.

[tried100times]

Thanks very much - I guess that explains why it has no effect!

Still in the ifort man page there is no mention of deprecation or the absence of the functionality so thats why I was confused.

If the man page is out of date, is there a better reference to use as I familirise myself with the compiler?

If you can control it manually thats fine. Actually I wanted dynamic openmp which I have achieved now by adding -liomp5 (since openmp-link had no effect).

[Steven_L_Intel1]

"Deprecated" means that we may remove it in a future release - it still works (or is supposed to). I also think that the decision to deprecate -openmp-link may be reversed, but that hasn't happened yet.

[t_clark]

Hi,

Thanks for this, tried100times. I only needed to try 20 times so I guess you helped me out.

I've followed the above thread (and your other -static-intel thread) and found them to be very helpful.

I encountered one last problem after the above. Having followed the same linking practise as above, I got the following error when executing my mexfunction:

Mex file entry point is missing. Please check the (case-sensitive)
spelling of mexFunction (for C MEX-files), or the (case-insensitive)
spelling of MEXFUNCTION (for FORTRAN MEX-files).
??? Invalid MEX-file '/home/thc29/Dropbox/syncTomoPIVtoolbox/code_tomoreconstruction/mxmart_large_pvr/mxmart_large_pvr_NP2.mexa64':

To solve this, it was necessary to move the intel libraries up in the link ine order... so my link line looks like this...

ifort $LINKFLAGS -Wl,--version-script,$TMWROOT/extern/lib/glnxa64/fexport.map -Wl,--no-undefined -o mxmart_large_pvr_NP2.$MEXEXT $MEXNAME.o /opt/intel/lib/intel64/libifcoremt_pic.a -Wl,-rpath-link,$TMWROOT/bin/glnxa64,-rpath,/opt/intel/composerxe-2011.1.107/compiler/lib/intel64/ -lm -liomp5 -L$TMWROOT/bin/glnxa64 -lmx -lmex -lmat

Cheers!

Tom

[t_clark]

OK, in response to my own solution that may not be the way. Somehow, it worked for me (once) then following a recompile started failing. I really have _No Idea_ what changed.

So, it might be worth a try - but I'd have to conclude that my response is far from a 'Robust Fix' for this problem. Has anyone ogo any ideas?