Linking Intel OpenMP library with GCC

[DarioMangoni]

Hi guys,
I know this is a very common and known issue, but I think that this forum has to have a specific thread on this in order to have an official answer.

I'm compiling with GCC and I'm using Intel MKL (that calls Intel OpenMP library).
Result: BOTH libgomp (from GCC) and libiomp5 (from Intel) are linked.
I would avoid this double-linking, but how?

On Intel User Guide I read that I should use:

gcc -fopenmp -c foo.c bar.c

gcc foo.o bar.o -liomp5 -lpthread -L<icc_dir>/lib

But this, however, does not avoid the troubles. If I use call ldd I will see that both libgomp and libiomp5 are still linked.

Accordingly to the User Guide I have to use the omp.h file of the compiler (so in this case gcc).
So: in order to not " inadvertently use inappropriate header/module files" should I move Intel omp.h header file somewhere else than the default location?
If so, what about any other application that doesn't know about the new non-default location of Intel omp.h?
I'm not developing just for myself... I cannot put a custom include argument to the compiler command-line just because of this fancy choice.

Maybe I misunderstood something...

Thanks,
Dario

Using gcc 5.3.1 with Intel Parallel Studio XE2016

[James_C_Intel2]

This isn't really the right place to ask this question, since the question has nothing to do with the internal implementation of the OpenMP runtime.

However...

You need to work out where the reference to libgomp.so is coming from. AFAICS that link line shouldn't be including it (but run it with -v and see). If it isn't, then it must be coming from some other shared library.(You can use ldd on a shared library to see its dependencies, or use readelf).

The omp.h is irrelevant; you should be using the one from gcc if you're compiling with gcc. 

[Andrey_C_Intel1 · Accepted solution]

If I use call ldd I will see that both libgomp and libiomp5 are still linked.

If you are using gcc as a linker it may link many libraries those actually are not needed.  Try to add linker option that avoids to link unneeded libraries:  -Wl,--as-needed.  Then check ldd again.  If libgomp is not in the list of dependencies any more, then all OpenMP entries were successfully linked against Intel OpenMP runtime, and the dependency on the libgomp was redundant.

I am also moving this post to the Intel C/C++ compiler forum, as the question is related to the compiler compatibility, and not related to the OpenMP open source library as Jim already mentioned.

Regards,
Andrey

[TimP]

Guessing that you may be running on linux (or maybe Mac), libiomp5 should take care of all the references set up via gcc -fopenmp and gcc omp.h.  So you shouldn't be linking libgomp if you have searched libiomp5 first.

Does it work better if you set the -L reference to your libiomp5 path ahead of -liomp5 in you link step?

You aren't showing enough of your link step to know what is going wrong.  You must choose the MKL libraries which correspond to libiomp5 (not those set up for libgomp and gfortran), to avoid linking with libgomp (or vice versa).  Doesn't MKL link advisor cover this?

Unlike the situation when libiomp5 was first introduced,  libgomp performs well enough now that you may not see a performance advantage in libiomp5.

If the question is really about MKL, that forum would be more appropriate.

https://software.intel.com/en-us/forums/intel-math-kernel-library

If you aren't running on an OS where libiomp5 and MKL support gcc, you won't find answers on Intel forum.

[DarioMangoni]

Thank you guys,
I am running Linux Fedora 23 my command line for my test program is

g++ main.cpp -o main -fopenmp -L/opt/intel/lib/ -liomp5 -lpthread

In the verbose output there is still the linking to -lgomp, with ldd and readelf I can still find libgomp;
 

If I follow Churbanov suggestions (that are the same provided by the MKL Link Line Advisor), appending -Wl,--as-needed I still get -lgomp in the verbose output, but ldd and readelf do NOT show any dynamic symbol related to libgomp, while I still have GOMP_parallel in the output of objdump. Profiling the code seems that libgomp is never used. So I think I will be fine!

Thank you again