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 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
