[Openmp-commits] [PATCH] D101960: [openmp] Drop requirement on library path environment variables

[Ye Luo via Phabricator via Openmp-commits]

ye-luo added a comment.

In D101960#2961133 <https://reviews.llvm.org/D101960#2961133>, @jdoerfert wrote:

> There are 3 problems here (ignoring our test setup which should be discussed separately):
>
> 1. make sure clang finds libomp.so
> 2. make sure libomp.so (or clang?) finds libomptarget.so
> 3. make sure libomptartget.so finds the plugins
>
> All of which have to work nicely with LD_LIBRARY_PATH.
>
> I think for 3 you can look at the current dir. That was discussed and, as long as it does work with LD_LIBRARY_PATH, that seems a win.
>
> For 2, why don't we install them in the same place? If so, we reduce it to problem 1) [after applying solution to 3)] no?
>
> For 1, doing something always backwards compatible that may or may not work on some platforms and configurations seems best. You had a proposal here already. If that works, let's do it.

For 1. If users prefer linking an alternative libomp.so, they should not use -fopenmp at linking and link libomp.so explicitly as a regular library. If users add -fopenmp to clang at linking, clang needs to link the libomp.so shipped with clang and set rpath to ensure libomp.so can be found at run even libomp.so doesn't exist on LD_LIBRARY_PATH. In this way, if a user would like to switch to anther libomp.so, they can still specify LD_LIBRARY_PATH.
For 2. Is libomp.so aware of libomptarget.so? I doubt. Anyway I'd like to see a similar logic as case 1 and the control option is -fopenmp-targets.

So addOpenMPRuntimeSpecificRPath seems aligned with what I described.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101960