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
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. ***