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

Fri May 3 11:28:29 PDT 2019

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
===================
Ye Luo, Ph.D.
Computational Science Division & Leadership Computing Facility
Argonne National Laboratory

Jeff Hammond <jeff.science at gmail.com> 于2019年5月3日周五 上午9:08写道：

> 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>
> 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>
>> 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.
>>
>>
>>
>> Best,
>>
>> Ye
>>
>> ===================
>> Ye Luo, Ph.D.
>> Computational Science Division & Leadership Computing Facility
>> Argonne National Laboratory
>>
>>
>>
>>
>>
>> Jeff Hammond <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> 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
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/openmp-dev
>>
>>
>>
>>
>> --
>>
>> Jeff Hammond
>> 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
> http://jeffhammond.github.io/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/openmp-dev/attachments/20190503/dbe9fcba/attachment-0001.html>