aboutsummaryrefslogtreecommitdiff
path: root/llvm/unittests/Support/Path.cpp
diff options
context:
space:
mode:
authorLei Zhang <antiagainst@google.com>2020-05-08 17:06:03 -0400
committerLei Zhang <antiagainst@google.com>2020-05-13 13:42:34 -0400
commita4441fcd12a6c097cca1f8cff6515b9ea9ae3cee (patch)
treec6ed63af5dd65639b6b0d78a2ee4b89037bd50c3 /llvm/unittests/Support/Path.cpp
parentd02fce2d149eaad90fd5bcc0579de868fa86526d (diff)
downloadllvm-a4441fcd12a6c097cca1f8cff6515b9ea9ae3cee.zip
llvm-a4441fcd12a6c097cca1f8cff6515b9ea9ae3cee.tar.gz
llvm-a4441fcd12a6c097cca1f8cff6515b9ea9ae3cee.tar.bz2
[mlir][vulkan-runner] Avoid dependency on LLVM libraries
The Vulkan runtime wrapper will be compiled to a shared library that are loaded by the JIT runner. Depending on LLVM libraries means that LLVM symbols will be compiled into the shared library. That can cause problems if we are using it with other shared libraries depending on LLVM, notably Mesa, the open-source graphics driver framework. The Vulkan API wrappers invoked by the JIT runner links to the system libvulkan.so. If it's Mesa providing the implementation, Mesa will normally try to load the system libLLVM.so for its shader compilation. That causes issues because the JIT runner already loaded the Vulkan runtime wrapper which has LLVM sybmols compiled in. So system linker will instruct Mesa to use those symbols instead. Differential Revision: https://reviews.llvm.org/D79860
Diffstat (limited to 'llvm/unittests/Support/Path.cpp')
0 files changed, 0 insertions, 0 deletions