Previously we made libomptarget link as an LLVM library so we have
access to the LLVM core libraries. After the initial patch stuck we can
now apply the same changes to the plugins. This will allow us to use
LLVM in all of libomptarget when we have uses for them. In the future
this should allow us to remove the dependencies on libelf, libffi,
and dl.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
openmp/libomptarget/plugins/ve/CMakeLists.txt | ||
---|---|---|
43 | why do we need NO_INSTALL_RPATH here but later set its property separately? |
openmp/libomptarget/plugins/ve/CMakeLists.txt | ||
---|---|---|
43 | I'm not exactly sure, that was a configuration the AMD people gave me that finally made it stop breaking on their CI system. I think we need to manually set it to the libomptarget install as well whereas that one would set it to the one that goes in /build/lib. Ideally in the future we'd just put everything in the same library instead of duplicating it, but getting these configurations right is pretty finicky. |
openmp/libomptarget/plugins/ve/CMakeLists.txt | ||
---|---|---|
43 | That doesn't look good. Is there any argument provided by add_llvm_library could do something similar, instead of having completely contrary setting? |
openmp/libomptarget/plugins/ve/CMakeLists.txt | ||
---|---|---|
43 | Not sure, I think the NO_INSTALL_RPATH only applies to the one installed under the /lib directory and not the one we manually install. it worked on my machine without the rpath / installation business but the only buildbot we have didn't like it. If I had access to the machine I could try to figure it out but I'm not really interested in pushing and reverting commits until it's happy. |
openmp/libomptarget/plugins/ve/CMakeLists.txt | ||
---|---|---|
43 | The script used by those systems are available right? |
why do we need NO_INSTALL_RPATH here but later set its property separately?