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 [1], 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 [1]: https://bugs.archlinux.org/task/48973#comment146238
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.
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.
*** Bug 686810 has been marked as a duplicate of this bug. ***
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.
Same here. I solved it by disabling the llvm use flag of mesa then removing sys-devel/llvm-9.0.1
I found that disabling llvm use flag of mesa is a bad idea. It made plasmashell painfully unresponsive.
*** Bug 719914 has been marked as a duplicate of this bug. ***
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.
(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.
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.
(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 .
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
(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!
In theory, We have a mechanism to fix this now, see bug 880671. i.e. We can enforce having the same LLVM enabled for mesa and kdevelop, although that starts to imply anything using opengl will need to do the same. It doesn't quite work there. If someone can hit this today, a full backtrace would be useful.