Original bug report: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=846410 We have Kdevelop compiled against LLVM-3.8. Some users started detecting that if their mesa drivers get compiled against LLVM-3.9 this last version will get loaded first and Kdevelop will crash at loading a project. You can find a backtrace at <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=846410#5> You can also check that the crash dissapears if a non-llvm-3.9 video driver is loaded at <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=846410#84>.
*** Bug 373525 has been marked as a duplicate of this bug. ***
*** Bug 373127 has been marked as a duplicate of this bug. ***
*** Bug 375892 has been marked as a duplicate of this bug. ***
It's really unfortunate, that this bug still persists even after several months now and with a new point release just out now! Solving this bug should have the highest priority right now! People who need to use the latest mesa drivers (like me) aren't able to use KDevelop for a prolonged time now.
Sorry, Roman, unfortunately there's no easy fix for this problem. If someone's got a good solution for this problem, without having us use libclang out of process, I'm all ears.
The *real* fix should come from LLVM itself by adding versioned symbols. This has happened for Debian a day or two ago, maybe this experience can be pushed upstream.
Thanks for your responses! What would be the right way to bring it to their attention? Can you link to what you mean by "happened for Debian a day or two ago"? I assume an intermediate solution to get KDevelop going again in the meantime is not possible or difficult as Kevin said.
@Lisandro: Wow, that's awesome to hear! Would love to learn more about it, too. Maybe send a mail to kdevelop-devel@kde.org?
Is this bug fixed? I just tried KDevelop out again and it didn't crash.
The Debian fix (and actually the right one) was to add ELF symbols versions to LLVM, see <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=849098> Sorry for the late reply. @Kevin please tell me if you still want the mail, but the fix should really happen in LLVM upstream or make distros carry a delta like we do now...
Could you point me to the patch(es)?
Sure: <https://anonscm.debian.org/viewvc/pkg-llvm/llvm-toolchain/branches/3.8/debian/patches/add_symbols_versioning.patch?revision=2493&view=markup>
*** Bug 382334 has been marked as a duplicate of this bug. ***
Has this been reported upstream? I just saw the issue with swrast loading the library from Ubuntu's llvm-toolchain-3.8 (dated June 29th 2017) while kdev-clang uses LLVM 4.0 from llvm.org (1:4.0~svn305187-1~exp1 from June 15th or so). And: do both libLLVM copies involved need to carry the patch or is it enough if one of them does? As I reported in my #382334, I have been able to work around the crash by making mesa's libLLVM a symlink to the one used by kdev-clang, for now without side-effects. YMMV, this may only be possible if the latter is newer than the former, for instance (that would apply to Qt libraries, for instance).
> Has this been reported upstream? I don't think it has yet, unfortunately. I'm going to discuss this on the LLVM mailing list as soon as possible. > And: do both libLLVM copies involved need to carry the patch or is it enough if one of them does? I'd presume if only one of the libLLVM copies carries the patch, that'd be enough.
Actually, there's already a patch (approved & merged) upstream which I forgot about: https://reviews.llvm.org/D31524 Thanks to Lisandro et al. @Lisandro: I think we can consider this fixed, correct? At least from our side, there's nothing else to -- upstream distros need to patch their LLVM copies.
I'm not holding my breath for them to backport this patch to older LLVM versions like 3.8 ...
(In reply to Kevin Funk from comment #16) [snip] > @Lisandro: I think we can consider this fixed, correct? At least from our > side, there's nothing else to -- upstream distros need to patch their LLVM > copies. Indeed, this is the way to go. I'm *really* glad this went this far :-)
FYI: https://bugs.launchpad.net/ubuntu/+source/llvm-toolchain-3.8/+bug/1709399
*** Bug 398243 has been marked as a duplicate of this bug. ***
There is a rather evident workaround (which I ended up applying myself). The Mesa culprit is the (gallium) LLVM-accelerated software rasteriser (swrast). I think this is typically used only for OpenGL operations on a remote display, but Mesa also comes with (or can be built to provide) a non-accelerated version. Remove or uninstall the accelerated driver or rebuild Mesa (with --disable-gallium-llvm --disable-gallium-llvm) and the problem goes away. With a reasonably modern CPU you shouldn't notice much of performance drop in the desktop eye candy that uses OpenGL. Sorry that I cannot be more specific, I did this months ago and didn't take note exactly how. It seems I simply rebuilt Mesa without the gallium-llvm stuff in a launchpad PPA.
(Of course, if you rebuild Mesa locally you can just as well make it use the same LLVM as KDevelop uses, in particular if it has the aforementioned patch...)
(In reply to RJVB from comment #21) This is not viable, because the LLVM swrast isn't the only rasteriser using LLVM. It is used also in R600 and RadeonSI Mesa drivers
Disabling LLVM support in mesa with --disable-gallium-llvm indeed prevents building some other drivers (the R300 and R600 at least). Whether that's acceptable depends on the hardware you're using. For me it is perfectly fine :)