[Openmp-dev] libgomp.so libiomp5.so softlinks

Cownie, James H via Openmp-dev openmp-dev at lists.llvm.org
Fri May 3 04:17:05 PDT 2019

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 at intel.com>
IAGS/CPDP/TCAR (Technical Computing, Analyzers, and Runtimes)
Tel: +44 117 9071438

From: Openmp-dev [mailto:openmp-dev-bounces at lists.llvm.org] On Behalf Of Ye Luo via Openmp-dev
Sent: Friday, May 3, 2019 5:20 AM
To: Jeff Hammond <jeff.science at gmail.com>
Cc: via Openmp-dev <openmp-dev at lists.llvm.org>
Subject: Re: [Openmp-dev] libgomp.so libiomp5.so softlinks

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.

Ye Luo, Ph.D.
Computational Science Division & Leadership Computing Facility
Argonne National Laboratory

Jeff Hammond <jeff.science at gmail.com<mailto:jeff.science at gmail.com>> 于2019年5月2日周四 下午10:25写道:
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.


On Thu, May 2, 2019 at 6:41 PM Ye Luo via Openmp-dev <openmp-dev at lists.llvm.org<mailto:openmp-dev at lists.llvm.org>> wrote:
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.
Ye Luo, Ph.D.
Computational Science Division & Leadership Computing Facility
Argonne National Laboratory
Openmp-dev mailing list
Openmp-dev at lists.llvm.org<mailto:Openmp-dev at lists.llvm.org>

Jeff Hammond
jeff.science at gmail.com<mailto:jeff.science at gmail.com>
Intel Corporation (UK) Limited
Registered No. 1134945 (England)
Registered Office: Pipers Way, Swindon SN3 1RJ
VAT No: 860 2173 47

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/openmp-dev/attachments/20190503/6612bf99/attachment-0001.html>

More information about the Openmp-dev mailing list