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

Ye Luo via Openmp-dev openmp-dev at lists.llvm.org
Thu May 2 21:20:19 PDT 2019


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/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/openmp-dev/attachments/20190502/08446e60/attachment.html>


More information about the Openmp-dev mailing list