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

Thu Jan 24 09:33:12 PST 2019

jdenny added a comment.

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

>

Thanks for reviewing.

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

Second, `-v` also reveals that `-L/usr/lib/gcc/x86_64-linux-gnu/7.3.0/../../../x86_64-linux-gnu` is before `-L/home/jdenny/llvm/bin/../lib`, and I have:

  $ ls -l /usr/lib/x86_64-linux-gnu/libomp.so
  lrwxrwxrwx 1 root root 11 Jan  7  2018 /usr/lib/x86_64-linux-gnu/libomp.so -> libomp.so.5

As a result:

  $ readelf -d a.out | grep libomp.so
   0x0000000000000001 (NEEDED)             Shared library: [libomp.so.5]

Now `LD_LIBRARY_PATH` cannot force `a.out` to find Clang's `libomp.so` because `a.out` wants `libomp.so.5`.

My guess is that you don't have such a `libomp.so.5` sitting in a system library directory, and so environment variables seem to work for you.  If you instead have a `libomp.so` in a system library directory, Clang is probably incorrectly pointing to it for linking, but, linking manages to succeed anyway, so `LD_LIBRARY_PATH` can then locate the right one.

Is there something in my setup that seems uncommon?  Surely many people who wish to build Clang locally could find themselves in this situation.

> I think this patch would effectively lose the ability to use a custom standalone build of the OpenMP runtime: When hacking on the runtime it's pretty convenient to only build and install the `openmp` repository and use environment variables to switch between different versions. When putting `libomp.so` into `lib/clang/9.0.0/lib/linux/x86_64` [1] this path will be very first one that Clang instructs the linker to look at. As a result the "custom" location that I specify in `LIBRARY_PATH` won't be honored and I'll always end up using the version installed next to the compiler.

You want a Clang that has its own `libomp.so` to be told to use a different `libomp.so`?  And you want to tell Clang that via `LIBRARY_PATH` not `-L`?  Is that correct?

First, I think your use case can suffer from the same problem with system libraries that I just described.  In that situation, `LIBRARY_PATH` doesn't seem to help locate the desired `libomp.so`, regardless of whether it's installed alongside Clang or installed from a standalone `openmp` repository.  However, I think you're not seeing that problem because your system libraries happen not to conflict.

Second, if you have a script, could you use something like `-L$MY_ENV_VAR`?  Unlike `LIBRARY_PATH`, `-L` does override system library directories for me, so I think `-L` is the right solution for your use case.

In summary, it seems this patch fixes confusing behavior for a use case common to LLVM users: building Clang in their home directories.  This patch breaks a use case that is more common to LLVM developers: using `LIBRARY_PATH` to mix versions of Clang and the OpenMP runtime.  However, that use case was broken anyway, and switching from `LIBRARY_PATH` to `-L` fixes that use case in both regards.

Does all that sound right?

> 1: This path doesn't exist in a current installation of `trunk`. Is any other project using this path in its default settings? Sorry, I haven't been following LLVM activities pretty closely for the last months.

I thought I had a decent solution because Clang already looks in that directory.  However, each subproject seems to do something a little different, and `LLVM_ENABLE_PER_TARGET_RUNTIME_DIR` affects the result.  I'm trying to better understand this now.

Repository:
  rOMP OpenMP

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

https://reviews.llvm.org/D55725