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

Hal Finkel via Phabricator via Openmp-commits openmp-commits at lists.llvm.org
Thu Jan 24 09:35:54 PST 2019


hfinkel added a comment.

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

> 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.
>
> 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.
>
> 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 don't believe that this is a concern. User-provided link paths, with -L, are added before the toolchain-provided paths. If you look at ToolChains/Gnu.cpp the ordering is:

  Args.AddAllArgs(CmdArgs, options::OPT_L);
  Args.AddAllArgs(CmdArgs, options::OPT_u);
  
  ToolChain.AddFilePathLibArgs(Args, CmdArgs);

so the -L things are added first, then the ToolChain-provided paths.

Of course, we should regardless prioritize the ease of our users vs. our own convenience (and you could just not have an in-tree build in your development environment). However, I think you're okay either way.


Repository:
  rOMP OpenMP

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

https://reviews.llvm.org/D55725





More information about the Openmp-commits mailing list