LLVM conflict with Gallium3D (swrast) driver #19606
Comments
|
It's having different versions of llvm both dynamically linked and loaded into the same process. @Keno knows more, and has been trying to get distro graphics driver maintainers to go back to linking llvm statically I believe. Not sure if their reasons for changing to shared library linking are better or worse or just different than ours. |
|
We went through this once before with having multiple llvm versions on disk at the same time, now we're getting to having multiple llvm versions in memory at the same time. I wonder if maybe llvm should version their namespace? |
|
Yeah complain to your Linux distribution. It's their fault. The Mesa projects strongly recommends against linking their drivers dynamically for this reason. This can also be fixed with a change to C++ semantics (and I have a patch pending to Clang that adds an attribute to opt into such semantics). Nevertheless, we may be forced to consider renaming LLVM symbols ourselves because of this. |
|
It looks like everyone is resolving this with the symbol versioning added to LLVM in: https://reviews.llvm.org/D31524 Unfortunately, that is not in 3.9, and may only help if both LLVM libraries are versioned (I've read something to that effect in one of the threads below, and Julia nightly on Ubuntu 17.04 still encounters this issue -- where mesa is using libLLVM-4.0). x-ref some upstream discussions: https://bugs.freedesktop.org/show_bug.cgi?id=93103 (FWIW there's a nice simple reproducer here: https://github.com/Axel-Naumann/llvm-mesa-reproducer , from https://sft.its.cern.ch/jira/browse/ROOT-7744) |
Should help with crashes when loading multiple libLLVM versions in the same process, as happens with mesa/llvmpipe when mesa is dynamically linked against libLLVM. See JuliaLang#19606
Should help with crashes when loading multiple libLLVM versions in the same process, as happens with mesa/llvmpipe when mesa is dynamically linked against libLLVM. See JuliaLang#19606 patch: https://reviews.llvm.org/D31524 commit: https://reviews.llvm.org/rL300496
Should help with crashes when loading multiple libLLVM versions in the same process, as happens with mesa/llvmpipe when mesa is dynamically linked against libLLVM. See JuliaLang#19606 patch: https://reviews.llvm.org/D31524 commit: https://reviews.llvm.org/rL300496
Should help with crashes when loading multiple libLLVM versions in the same process, as happens with mesa/llvmpipe when mesa is dynamically linked against libLLVM. See #19606 patch: https://reviews.llvm.org/D31524 commit: https://reviews.llvm.org/rL300496
Should help with crashes when loading multiple libLLVM versions in the same process, as happens with mesa/llvmpipe when mesa is dynamically linked against libLLVM. See #19606 patch: https://reviews.llvm.org/D31524 commit: https://reviews.llvm.org/rL300496 Ref #25597 (cherry picked from commit edabf42)
Should help with crashes when loading multiple libLLVM versions in the same process, as happens with mesa/llvmpipe when mesa is dynamically linked against libLLVM. See #19606 patch: https://reviews.llvm.org/D31524 commit: https://reviews.llvm.org/rL300496 Ref #25597 (cherry picked from commit edabf42)
The Gallium 3D driver (swrast) uses llvm to compile shaders. Running e.g. a QML application from within Julia causes a segfault (backtrace at the end of this post).
I added a package that reproduces the problem fairly easily:
https://github.com/barche/LoadQML.jl
The problem was confirmed in VirtualBox running Ubuntu 16.04 with the official 0.5 binary and on Fedora 25 using the distribution julia 0.5. The problem goes away when disabling the llvmpipe driver. The exact same C++ code works with the llvmpipe driver when loading the same QML in a standalone app (in the
deps/usr/bindirectory of the LoadQML package), so using llvm only in Gallium3D or only in Julia is fine.I'm not sure if the cause here is Julia, Gallium3D or LLVM itself.
The text was updated successfully, but these errors were encountered: