| 2017-08-08 16:53:39 |
RJVB |
description |
The libgl1-mesa-dri-lts-xenial package depend on libLLVM-3.8.so.1 from the libllvm3.8v4 package; this library gets used when using software OpenGL rendering on a remote display. As a result, applications based on Qt5 that also use libLLVM features provided by another (newer) LLVM version will crash when invoked from a remote X terminal.
Example: KDevelop5 uses libclang (and this libLLVM) for C/C++ parsing; I build it to use the LLVM/Clang 4.0 packages from llvm.org (and self-built Qt5 and KF5 libraries) and can thus not render to a remote X server (XQuartz on my Mac).
There is an upstream LLVM patch which solves the issue by adding versioning info to libLLVM:
https://bugs.kde.org/show_bug.cgi?id=373614
https://reviews.llvm.org/D31524
Please consider backporting this patch to LLVM 3.8 (or rebuilding the mesa package to use an LLVM version that already contains the patch). |
The libgl1-mesa-dri-lts-xenial package depend on libLLVM-3.8.so.1 from the libllvm3.8v4 package; this library gets used when using software OpenGL rendering on a remote display. As a result, applications based on Qt5 that also use libLLVM features provided by another (newer) LLVM version will crash when invoked from a remote X terminal.
Example: KDevelop5 uses libclang (and this libLLVM) for C/C++ parsing; I build it to use the LLVM/Clang 4.0 packages from llvm.org (and self-built Qt5 and KF5 libraries) and can thus not render to a remote X server (XQuartz on my Mac).
There is an upstream LLVM patch which solves the issue by adding versioning info to libLLVM:
https://bugs.kde.org/show_bug.cgi?id=373614
https://reviews.llvm.org/D31524
Please consider backporting this patch to LLVM 3.8 (or rebuilding the mesa package to use a (much) more recent LLVM version that already contains the patch). |
|
