5.2.1 appimage parser problem

[Yavuz Mert]

Hi all,
I have several opensuse leap 42.3 installations (home/work) with
distribution provided 5.1.2 kdevelop with working c++ parsers. But when i
use 5.2.1 appimage I get tons of clang errors and parser does not work at
all. I first thought it was a problem with version 5.2.1 since appimage is
supposed to be self contained and should not conflict with system
libraries/clang.
But, now i upgraded my home system to opensuse beta and 5.2.1 appimage
parser now works. Does anybody have similar problems with appimage. If
Appimage packager is on the mailing list, can guide me to trace the error
and fix appimage to work regardless of the host OS.

thanks
yavuz

[René J.V. Bertin]

Hi,

Post by Yavuz Mert
use 5.2.1 appimage I get tons of clang errors and parser does not work at
all. I first thought it was a problem with version 5.2.1 since appimage is
supposed to be self contained and should not conflict with system
libraries/clang.

There is one possibility for interaction that I know of: Mesa. It has a software GL emulation driver (for Gallium IIRC) that is based on LLVM. I run into that regularly when I use KDevelop on a remote display; it usually causes weird crashes because of mixing and (mis)matching two libLLVM version at runtime. In my case I can solve it by making the libLLVM used by Mesa a symlink to the (much newer) one used by the KDevelop clang parser.

To check if this is also the cause of your problem you'd need to locate the temp. directory into which the KDevelop appimage is unpacked, find the libLLVM in it, extract it and copy it alongside the library used by Mesa. You can then redirect the symlink used by Mesa. In my case that's libLLVM-3.8.so.1 ;

lrwxrwxrwx 1 root root 20 Feb 9 14:30 /usr/lib/x86_64-linux-gnu/libLLVM-3.8.so.1 -> libLLVM-3.8.so.1.org
-rw-r--r-- 1 root root 40362424 Jul 18 2017 /usr/lib/x86_64-linux-gnu/libLLVM-3.8.so.1.org

When I need to run KDevelop remotely I have to do

%> sudo ln -sf libLLVM-5.0.so.1 /usr/lib/x86_64-linux-gnu/libLLVM-3.8.so.1

(For some reason something restores the link automatically so I don't run the risk of forgetting about this kludge...)

R.