Hi,
What is the reason of making both libgomp.so libiomp5.so softlinks to libomp.so?
I found them hijacking my application built with GNU and Intel compilers when I put llvm library folder on my LD_LIBRARY_PATH. This is very annoying. Unless there is a very good reason, I think they need be removed.
Best,
Ye
The LLVM and Intel OpenMP runtimes are essentially identical.
The LLVM/Intel OpenMP runtime defines the GOMP symbols and works with GCC OpenMP codes, which is actually a good thing, because the GOMP runtime performs worse (https://www.nextplatform.com/2017/03/15/arm-antes-hpc-software-stack/).
There are a number of solutions to your problem. One is to control LD_LIBRARY_PATH appropriately. You can remove LLVM folders from LD_LIBRARY_PATH and use LD_PRELOAD at runtime or -Wl,-rpath when linking to tell your LLVM OpenMP binary where the library is.
The best option, of course, is to link statically. You are a Blue Gene user so I’m sure you understand the utility of fully static binaries 
Regardless of how you solve this, I object to removing the symlinks. What is happening because of this is far better than the alternative of having multiple OpenMP libraries loaded into a single binary. It is a reasonable assumption that if you are setting LLVM OpenMP shared libraries in your global path (LD_LIBRARY_PATH), then you want that library to be used. If not, link differently.
Jeff
Hi Jeff,
No matter how good LLVM OpenMP runtime is, libgomp may be intended when I build my app with GNU.
Intel OpenMP runtime and LLVM runtime can differ in versions. In my case, they are not identical.
When my app runs, I get tons of omp_nested deprecation warnings from libomp via MKL.
I avoid seeing the warnings with a real libiomp5 shipped with Intel release.
The potential risk of “having multiple OpenMP libraries loaded into a single binary” is a bit convincing.
If I build my app with clang and MKL, having two openMP runtime is clearly bad.
At the moment, I’d like to having one app built with Intel to use Intel runtime and I don’t need to see all the warnings.
When I work on another app, I just use the llvm OpenMP runtime. Manipulating LD_LIBRARY_PATH or rpath or LD_PRELOAD is anyway painful.
I think I can live with this. It is better than the frustration seeing code crashing due two conflicting OpenMP runtime libraries.
Sadly, BG/Q is about to disappear and I mostly use dynamically linking for convenience and also a requirement for GPU.
I don’t see a good solution but It seems that the current solution is the less bad one.
Thank you, Jeff.
Best,
Ye
Jeff Hammond <jeff.science@gmail.com> 于2019年5月2日周四 下午10:25写道：
Static linking the OpenMP runtime is generally a bad idea.
As soon as you do that it becomes very easy to end up with multiple OpenMP runtimes in the same process, and have no way to avoid it.
Imagine one support library statically linked with libiomp5, and another statically linked with libgomp; as soon as you link against these two libraries you have two OpenMP runtimes in the same process and there’s no way to avoid it. Even if you statically link against the same runtime you can run into problems, since you are clearly forcing two copies into the process (libomp and libiomp5 try to detect this, but it’s all pretty edgy :-)).
– Jim
Jim Cownie james.h.cownie@intel.com
IAGS/CPDP/TCAR (Technical Computing, Analyzers, and Runtimes)
Tel: +44 117 9071438
At least on Linux, the linker reads left-to-right and if it gets all the symbols it needs from one library, it’s not going to look in another. I don’t see how static linking fails with OpenMP unless the compiler looks for symbols associated with two implementations (and not just Intel and GOMP, because the former supports nearly all of the latter’s runtime API). I’ve only heard of this happening with Cray or IBM compilers…
Jeff
It is most frequently Windows folks who want to ship their product as a shared library with no other dependencies who want to link the OpenMP runtime into it, and then get annoyed when we don’t provide a static library. They are used to doing that with other libraries, and don’t realise that a threading library has important additional state.
I believe that it is also possible (on ELF based machines) to link a library statically and then not export the library symbols, which would mean that your “The linker will find the necessary symbols so not load another library” is not necessarily true…
– Jim
Jim Cownie james.h.cownie@intel.com
IAGS/CPDP/TCAR (Technical Computing, Analyzers, and Runtimes)
Tel: +44 117 9071438
I think even just Intel and GOMP, you can get both of them in the binary with static linking.
When I build OpenBLAS with GNU and put GOMP inside the libopenblas.a.
Then I compile my app with Intel compiler and link libopenblas.a. Base on the left to right rule, Intel runtime will be appended after the static library and I get two runtime inside the binary.
Ye
Jeff Hammond <jeff.science@gmail.com> 于2019年5月3日周五 上午9:08写道：