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 #include <stdio.h> 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 and addresses three use cases:
- 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/9.0.0/x86_64-unknown-linux-gnu/lib, 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. 9.0.0 and x86_64-unknown-linux-gnu are expanded from PACKAGE_VERSION and LLVM_DEFAULT_TARGET_TRIPLE.
- openmp is built standalone and either (a) the new cmake variables OPENMP_CLANG_VERSION and OPENMP_CLANG_TARGET_TRIPLE are specified or, if not, (b) their values are successfully obtained from the selected C++ compiler because it's a clang that supports the --print-target-triple option:
- In the install tree, openmp libraries appear in the same places as in case 1. Automatically computing the name of the clang-dedicated directory when the C++ compiler is clang and then installing copies of the openmp libraries there is useful in the following scenario: 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 whatever clang you're using doesn't know where to find the openmp build directory.
- In the install tree, openmp libraries appear in the same places as in case 1. Automatically computing the name of the clang-dedicated directory when the C++ compiler is clang and then installing copies of the openmp libraries there is useful in the following scenario: building openmp after clang in order to build bitcode libraries as in step 4 in the following instructions:
- openmp is built standalone and either OPENMP_CLANG_VERSION or OPENMP_CLANG_TARGET_TRIPLE is not specified or computed: 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.
The way this is computed looks different to me than what I believe to be the corresponding code in libc++'s file. It's this, right?