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

Fri May 3 07:53:05 PDT 2019

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

From: Jeff Hammond [mailto:jeff.science at gmail.com]
Sent: Friday, May 3, 2019 3:09 PM
To: Cownie, James H <james.h.cownie at intel.com>
Cc: Ye Luo <xw111luoye at gmail.com>; Openmp-dev <openmp-dev at lists.llvm.org>
Subject: Re: [Openmp-dev] libgomp.so libiomp5.so softlinks

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

On Fri, May 3, 2019 at 4:17 AM Cownie, James H <james.h.cownie at intel.com<mailto:james.h.cownie at intel.com>> wrote:
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<mailto: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<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<mailto:jeff.science at gmail.com>>
Cc: via Openmp-dev <openmp-dev at lists.llvm.org<mailto: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.

Best,
Ye
===================
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.

Jeff

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:
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
===================
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>
https://lists.llvm.org/cgi-bin/mailman/listinfo/openmp-dev

--
Jeff Hammond
jeff.science at gmail.com<mailto:jeff.science at gmail.com>
http://jeffhammond.github.io/

---------------------------------------------------------------------
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.

--
Jeff Hammond
jeff.science at gmail.com<mailto:jeff.science at gmail.com>
http://jeffhammond.github.io/
---------------------------------------------------------------------
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/81a44a92/attachment-0001.html>