openmp - Telling GCC to *not* link libgomp so it links libiomp5 instead -

i need figure out compiler/linker directive can feed gcc won't automatically link libgomp when -fopenmp specified.

the reason i'm trying build against intel's mkl blas. mkl requires adding separate intel library handle multithreading (e.g., libmkl_intel_thread or libmkl_gnu_thread). library linking mkl against libgomp, however, not available on every operating system, including mine. forces me link libmkl_intel_thread, in turn must link against libiomp5.

while able build package, binaries linked against both libgomp , libiomp5. i'm not positive causing problems, there have been few crashes, linkage-combination suspicious, , if isn't causing crashes terrible inefficiency.

i'm trying gcc 4.9.1.

avoiding -fopenmp is, unfortunately, not option. reason compiling rather large package comprised of several sub-packages, makefiles not in greatest shape, , additional packages other sources (plug-ins) may compiled later. forcing universal compiler/linker directive isn't difficult. turning on --enable-openmp, however, activates both -fopenmp, , defines used trigger code related multi-threading. trying separate 3 (--enable-openmp, -fopenmp, , code linked --enable-openmp) isn't feasible.

i've looked through manual pages, , don't see directive gcc allow selection of openmp library. intel's forums have old discussion in suggest specifying static library after -fopenmp followed --as-needed. seems pretty rickety, , has lot of potential interfere plugin packages. llvm-openmp seems have considered -fopenmp=libiomp5 directive @ 1 point, seems have been dropped in 3.5 release , i'm trying use gcc anyway.

thanks.

gcc not support linking against intel openmp runtime library. gcc's internal code transformer translates openmp directives ligomp-specific calls , have way different api 1 exposed libiomp. also, mixing 2 separate openmp runtimes 1 executable (or single process, if openmp-enabled modules being loaded dynamically) recipe disaster. that's reason why mkl's multithreaded driver comes in 2 flavours - intel 1 , gnu one. latter missing on machines defect of installation.

edit: apparently intel openmp runtime provides gnu compatibility layer, means possibly used drop-in replacement of libgomp. @ least symbols there:

$ nm libiomp5.a | sort | grep gomp_ 0000000000000000 t gomp_barrier@@version 0000000000000000 t gomp_barrier@gomp_1.0 0000000000000000 t __kmp_api_gomp_barrier 0000000000000000 t __kmp_api_gomp_barrier_10_alias ... 

in case, have is:

• keep -fopenmp while compiling code gcc recognise openmp pragmas , transform code corresponding calls libgomp;
• if gcc used link executable or shared library, do not pass -fopenmp option during linking phase; instead, pass -l/path/to/libiomp5 -liomp5;
• if gnu ld used link executable/module, replace -lgomp -liomp5.

if not possible aforementioned changes, thread on intel's forums makes sense because of way linker resolves link-time symbol references, though more of hack. passing -wl,--as-needed forces gnu ld not emit dt_needed tags library follows on command line unless library satisfies undefined symbol reference, assumption being gcc driver insert -lgomp somewhere after user-supplied options. idea prevent libgomp being linked executable when there no unresolved references gomp_..., should not case since references, dynamically loaded modules, should satisfied libiomp5. preventing libgomp being loaded rtld essential since there constructor routines in called no matter if symbols being imported or not , things might interfere iomp.

the linker trick won't work on non-elf systems os x. mach-o link editor not support --as-needed though there might different mechanism achieve same result on os.