[Openmp-commits] [PATCH] D55725: [OpenMP] Add libs to clang-dedicated directories

Fri Jan 25 08:30:04 PST 2019

jdenny added a comment.

In D55725#1370823 <https://reviews.llvm.org/D55725#1370823>, @Hahnfeld wrote:

> In D55725#1369528 <https://reviews.llvm.org/D55725#1369528>, @jdenny wrote:
>
> > In D55725#1369006 <https://reviews.llvm.org/D55725#1369006>, @Hahnfeld wrote:
> >
> > > In the summary you said that you don't want to set `-L` when compiling which I totally understand, me neither. Did you try setting `LIBRARY_PATH` in the environment to make Clang automatically add the directory containing `libomp.so`? That's what we do and the combination of `LIBRARY_PATH` during compilation and `LD_LIBRARY_PATH` during execution makes sure that (a) all libraries are found and (b) they are found in the very same version that were used when linking the binary.
> >
> >
> > `LIBRARY_PATH` during compilation has no effect for me.
> >
> > First, `-v` reveals that `-L/home/jdenny/llvm/bin/../lib` is before `-L/home/jdenny/llvm/lib`, which is added by `LIBRARY_PATH`, which is thus redundant here.
>
>
> Are you saying a manual `-L` trumps the environment variable `LIBRARY_PATH`? Yes, that makes sense, I guess.

While that's true, that's not the point I was making here.  You suggested I set `LIBRARY_PATH` to find Clang's `libomp.so`, so I set it to my installed library directory, `/home/jdenny/llvm/lib`.  My point here is that Clang reads `LIBRARY_PATH` and adds `-L/home/jdenny/llvm/lib` to the linker command line //after// `-L/home/jdenny/llvm/bin/../lib`, which it adds regardless, so `LIBRARY_PATH` proves redundant.

In other words, `LIBRARY_PATH` generally doesn't seem helpful for Clang's own `lib` directory, even when there's no conflicting system library.  Sorry, maybe that's not helpful to point out.

>> Now `LD_LIBRARY_PATH` cannot force `a.out` to find Clang's `libomp.so` because `a.out` wants `libomp.so.5`.
> 
> Please note that `libomp.so.5` is an invention of Debian. None of upstream's CMake files will ever create a symlink with that name!
>  (We could think about adding such symlink, there was a complaint sometime ago that we don't have versioned shared libraries. But that wouldn't solve all problems, the linker would still use the "wrong" file.)

Let me see if I understand this.  Sorry if I have it all mixed up.  For some `N`, if Clang looks for `libomp.so.N` instead of `libomp.so`, and if we could be sure that all copies of `libomp.so.N` that might be seen are ABI-compatible, and if no such `libomp.so.N` is yet another symlink, then it shouldn't matter if the linker uses the wrong file, and all that matters is that `LD_LIBRARY_PATH` chooses the right one.  Is that right?  I feel like that ABI-compatibility assumption is shaky, but I don't have enough practical experience here.

>> My plan for the non-symlinks is:
>> 
>> - Always install to `lib` in case that matters for backward compatibility.
>> - With `-DLLVM_ENABLE_PER_TARGET_RUNTIME_DIR=True`, additionally install to `lib/clang/9.0.0/x86_64-unknown-linux-gnu/lib`.
> 
> SGTM. Did you consider a symlink to the shared library in `lib` to avoid duplication?

Good idea.

Repository:
  rOMP OpenMP

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D55725/new/

https://reviews.llvm.org/D55725