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

[Joel E. Denny via Phabricator via Openmp-commits]

jdenny created this revision.
jdenny added reviewers: ABataev, Hahnfeld, tra, grokos, jlpeyton.
Herald added subscribers: guansong, mgorny.

Clang by default prefers system openmp libraries over the ones built
alongside clang.  The effect is that clang-compiled openmp
applications sometimes misbehave if the user doesn't adjust the
library search path.

For example, where $LLVM_INSTALL_DIR is something like
/home/jdenny/llvm and is built from git master, but where my system
openmp libraries under /usr/lib/x86_64-linux-gnu are built from LLVM
6.0:

  $ cd $LLVM_INSTALL_DIR
  $ cat test.c
  int main() {
    #pragma omp target teams
    printf("hello\n");
    return 0;
  }
  $ ./bin/clang -fopenmp -fopenmp-targets=nvptx64 test.c
  $ ./a.out
  ./a.out: error while loading shared libraries: libomptarget.so: cannot open shared object file: No such file or directory
  $ LD_LIBRARY_PATH=lib ./a.out
  Segmentation fault (core dumped)
  $ LD_LIBRARY_PATH=lib ldd a.out | grep libomp
          libomp.so.5 => /usr/lib/x86_64-linux-gnu/libomp.so.5 (0x00007fab59748000)
          libomptarget.so => lib/libomptarget.so (0x00007fab59515000)

Of course, I can specify -L to link against the right libomp.so, but
it seems like clang should just do that for me automatically.

This patch makes that happen.  However, I am not confident that this
patch is the right thing to do and that it doesn't conflict with any
existing plans for openmp library organization.  At the very least, I
hope discussion of this patch will help me to better understand the
current thinking.

This patch addresses three use cases:

1. openmp and clang subprojects are built together: In this case, in both the build and install trees, all openmp libraries appear in the lib directory as they do without this patch, but they also appear in a clang-dedicated directory, lib/clang/8.0.0/lib/linux/x86_64, for which clang then adds a -L. This patch doesn't need to adjust clang for that to happen as clang without this patch already looks in that directory.  "linux" and "x86_64" are expanded from CMAKE_SYSTEM_NAME and CMAKE_SYSTEM_PROCESSOR.

2. openmp is built standalone but -DOPENMP_CLANG_VERSION=8.0.0 (a new cmake variable) is specified:
  - In the install tree, openmp libraries appear in the same places as in case 1.  The clang-dedicated directory is useful here when building openmp after clang in order to build bitcode libraries as in step 4 in the following instructions:

    https://www.hahnjo.de/blog/2018/10/08/clang-7.0-openmp-offloading-nvidia.html
  - In the build tree, openmp libraries appear only where they do without this patch (various directories in the build tree).  In this case, I'm not sure how a clang-dedicated directory can be useful given that clang doesn't know where to find the openmp build directory.

3. openmp is built standalone and -DOPENMP_CLANG_VERSION is not specified: In this case, in both the build and install trees, openmp libraries appear only where they do without this patch (for the install tree, that's the main lib directory).  We cannot create clang-dedicated directories when there's no clue what clang the standalone openmp build was intended for.

A few details that probably need consideration:

1. It's not clear to me that CMAKE_SYSTEM_NAME and CMAKE_SYSTEM_PROCESSOR are the right choices for all openmp libraries, but it at least produces correct behavior for the example above.

2. In the clang-dedicated directories, I didn't bother to install the libiomp5.so and libgomp.so sym links.

3. I am not a Windows developer.  I'm assuming that the clang-dedicated directories make sense there.


Repository:
  rOMP OpenMP

https://reviews.llvm.org/D55725

Files:
  openmp/CMakeLists.txt
  openmp/libomptarget/deviceRTLs/nvptx/CMakeLists.txt
  openmp/libomptarget/plugins/CMakeLists.txt
  openmp/libomptarget/plugins/cuda/CMakeLists.txt
  openmp/libomptarget/src/CMakeLists.txt
  openmp/runtime/src/CMakeLists.txt

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D55725.178295.patch
Type: text/x-patch
Size: 9087 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/openmp-commits/attachments/20181214/a5c594fa/attachment.bin>