The changes in D122444 caused OpenMP programs built with the
LLVM_ENABLE_RUNTIMES options to stop finding the libraries. We generally
expect to link against the libraries associated with the clang
installation itself but we no longer implicitly included that directory.
This patch adds in the include path of the clang installations library
to ensure we can find them.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
s/include/library (commit message and code)
add test.
Assuming both are easy to fix, LG.
Another idea is to refactor tools::addOpenMPRuntime to use the full path of libomp.so or libomp.a instead of -LXXX -lomp.
The two ways have identical semantics when libomp.so has a DT_SONAME tag.
In the long term, perhaps libomp.so should be installed to the multiarch directory like lib/x86_64-unknown-linux-gnu/libc++.so.
clang/lib/Driver/ToolChains/CommonArgs.cpp | ||
---|---|---|
741 | XXXIncludePath usually refers to the preprocessor include path. |
It's technically possible for the runtime libraries to live somewhere else, I forget if any of our testers have a setup like that.
In the long term, perhaps libomp.so should be installed to the multiarch directory like lib/x86_64-unknown-linux-gnu/libc++.so.
Could you elaborate on the benefits of using the multiarch directory? I'm not familiar with it.
using the multiarch directory
If we can cross compile libomp and libomptarget to the target system. We may have
lib/x86_64-unknown-linux-gnu/libomp.so
lib/aarch64-unknown-linux-gnu/libomp.so
Compile clang once but compile runtime library for multiple architectures.
Yes, mostly for deambiguating cross compiling and multilib style -m32/-m64.
In addition, I think all LLVM_ENABLE_RUNTIMES projects but openmp switched to lib/$triple/xxx.so for runtime libraries, e.g. libc++.so, libc++abi.so, libunwind.a.
By switching openmp we will improve consistency. Downstream distributions can use the same way to install runtime libraries, instead of doing different things for openmp and non-openmp.
I'm all for it ;). Assuming @jhuber6 is not looking at that right now we need an issue to track this.
Sounds good, I won't look at it immediately but I could set up an issue to track the transition.
XXXIncludePath usually refers to the preprocessor include path.