|Summary:||dev-util/kdevelop:5 and media-libs/mesa-17*[llvm] link with different slots of sys-devel/llvm, resulting in a runtime symbol conflict and crash|
|Product:||Gentoo Linux||Reporter:||Matt Whitlock <gentoo>|
|Component:||Current packages||Assignee:||Gentoo KDE team <kde>|
|Severity:||normal||CC:||ao, cyp561, email200202, kripton, Letto2, llvm, mgorny|
|Package list:||Runtime testing required:||---|
Description Matt Whitlock 2018-03-27 01:02:28 UTC
dev-util/kdevelop-5.2.1 (/usr/lib64/qt5/plugins/kdevplatform/30/kdevclangsupport.so) links with sys-devel/llvm:6, but media-libs/mesa-17.3.7 (/usr/lib64/dri/radeonsi_dri.so) links with sys-devel/llvm:5. According to , it can be possible for a process to load two different versions of LLVM libraries but only if LLVM is built using Autotools, not CMake. Since Gentoo's sys-devel/llvm is built using CMake, its libraries do not have versioned symbols. Thus, when kdevelop loads two different versions of LLVM, the symbols clash, and the second copy of LLVM attempts to initialize state that was already initialized by the first copy of LLVM, resulting in the following crash: mesa: CommandLine Error: Option 'help-list' registered more than once! LLVM ERROR: inconsistency in registered CommandLine options : https://bugs.archlinux.org/task/48973#comment146238
Comment 1 Matt Whitlock 2018-03-27 01:38:51 UTC
Upgrading to media-libs/mesa-18.0.0_rc5 eliminated the dependency on sys-devel/llvm:5, so now kdevelop works again, but this is not a proper solution, as it will break again when kdevelop links with LLVM 7 but Mesa is still stuck on LLVM 6.
Comment 2 Michał Górny 2018-03-29 07:33:11 UTC
I don't think there's any easy way to fix this. Options are: 1. Get symbol versioning upstream. I think I've seen something on the topic but I don't know the details and Phabricator has the most useless search I've ever seen. Plus, it's unclear if it's really going to fix all the issues or only a few apparent ones. 2. Use a cheap hack in dependencies/blocks of kdeveloper to disallow mesa versions with different LLVM_MAX_SLOT. This is going to be PITA to maintain, and will not even be guaranteed to work (it will mostly rely on PM rebuilding both mesa and kdevelop after possible LLVM upgrade, and PM aggressively trying to upgrade stuff). 3. Add USE flags to control LLVM version linked, and require match betwen kdevelop and mesa. Total PITA to maintain and PITA to users. 4. Stop slotting LLVM. Solves a lot of the problems at the cost of killing old software.
Comment 3 Andreas Sturmlechner 2019-05-27 10:52:40 UTC
*** Bug 686810 has been marked as a duplicate of this bug. ***
Comment 4 Matt Whitlock 2020-03-29 22:19:50 UTC
This problem has resurfaced for me today. I upgraded to sys-devel/llvm-10.0.0, but media-libs/mesa-20.0.2 is still linked against LLVM 9. Thus, I am again unable to start KDevelop. I suppose my only option is to uninstall LLVM 10, mask it, and rebuild KDevelop. What a disaster. Kinda makes one appreciate the way Windows loads DLLs in a strict dependency tree, versus the flat import namespace of the GNU dynamic linker.
Comment 5 email200202 2020-03-30 12:17:11 UTC
Same here. I solved it by disabling the llvm use flag of mesa then removing sys-devel/llvm-9.0.1
Comment 6 email200202 2020-03-31 05:17:04 UTC
I found that disabling llvm use flag of mesa is a bad idea. It made plasmashell painfully unresponsive.
Comment 7 Andreas Sturmlechner 2020-04-29 10:20:45 UTC
*** Bug 719914 has been marked as a duplicate of this bug. ***
Comment 8 Tomasz Golinski 2020-05-02 21:20:31 UTC
I noticed the same error today with both LLVM:9 and :10 installed, mesa-20.0.6. However simple rebuild of kdevelop solved the problem for me.
Comment 9 Plüss Roland 2020-07-22 14:54:10 UTC
(In reply to Tomasz Golinski from comment #8) > I noticed the same error today with both LLVM:9 and :10 installed, > mesa-20.0.6. However simple rebuild of kdevelop solved the problem for me. Not working for me. Rebuilding KDevelop still and it is still broken. It seems if 10.0.1.9999 LLVM could be installed the problem would be gone since Mesa ebuild shows this to be supported. I am though unable to get it unmasked, no matter what I try.
Comment 10 Andreas Sturmlechner 2020-07-22 14:55:54 UTC
The workaround is relatively simple. Rebuild mesa *and* kdevelop, that makes sure they link against the same (latest) version of llvm. No reason to unmask live versions at all.
Comment 11 Plüss Roland 2020-07-22 21:06:22 UTC
(In reply to Andreas Sturmlechner from comment #10) > The workaround is relatively simple. Rebuild mesa *and* kdevelop, that makes > sure they link against the same (latest) version of llvm. > > No reason to unmask live versions at all. No, this is not possible for the simple reason that Clang/LLVM wants to update to 10.0 version. Mesa can not use 10.0 only 10.0.1.9999. For this reason Mesa pulls in LLVM 9 and the problem starts. I could only get the situation solved by masking Clang/LLVM/LLVMGold >10.0 and forcing like this all to use 9.0. This situation needs a fix since right now 10.0 and 9.0 is pulled in at the same time without hard-masking 10.0 .
Comment 12 Andreas Sturmlechner 2020-07-22 21:08:54 UTC
That's BS, unless you never sync your tree. Please don't further spam the bug with this non-issue. # equery l mesa kdevelop llvm * Searching for mesa ... [IP-] [ ] media-libs/mesa-20.0.8:0 * Searching for kdevelop ... [IP-] [ ] dev-util/kdevelop-5.5.2:5/55 * Searching for llvm ... [IP-] [ ] sys-devel/llvm-10.0.1:10
Comment 13 Plüss Roland 2020-07-23 07:39:56 UTC
(In reply to Andreas Sturmlechner from comment #12) > That's BS, unless you never sync your tree. Please don't further spam the > bug with this non-issue. > > # equery l mesa kdevelop llvm > * Searching for mesa ... > [IP-] [ ] media-libs/mesa-20.0.8:0 > > * Searching for kdevelop ... > [IP-] [ ] dev-util/kdevelop-5.5.2:5/55 > > * Searching for llvm ... > [IP-] [ ] sys-devel/llvm-10.0.1:10 For your information: I synced two days ago. But if you are so f*** rude then okay, I go away... but seriously, that's no behavior. BYE!