Bug 369105 - KDevelop-5.0.1 AppImage doesn't launch on Gentoo because of "libxcb-dri3.so.0: error: symbol lookup error"
Summary: KDevelop-5.0.1 AppImage doesn't launch on Gentoo because of "libxcb-dri3.so.0...
Alias: None
Product: kdevelop
Classification: Applications
Component: general (show other bugs)
Version: unspecified
Platform: Appimage Linux
: NOR normal
Target Milestone: ---
Assignee: Sven Brauch
URL: https://paste.pound-python.org/raw/cB...
Depends on:
Reported: 2016-09-20 08:42 UTC by Petros
Modified: 2018-12-27 22:05 UTC (History)
4 users (show)

See Also:
Latest Commit:
Version Fixed In:

LD_DEBUG="symbols" ./KDevelop-5.0.80-x86_64.AppImage (214.30 KB, application/gzip)
2017-01-18 01:10 UTC, rjwgnr27

Note You need to log in before you can comment on or make changes to this bug.
Description Petros 2016-09-20 08:42:12 UTC
I use Gentoo/Linux and I have installed KDevelop-5.0.1 with a custom ebuild an works like a charm. Although I wanted to download and test an AppImage with the same version from here: 


For some reason *this* KDevelop executable (appimage) can't launch and rants about " /usr/lib64/libxcb-dri3.so.0: error: symbol lookup error: undefined symbol: xcb_send_request_with_fds ". I am providing one URL with the output of command:

LD_DEBUG=”libs” && ./KDevelop-5.0.1-x86_64.AppImage 

and onother of the command:

LD_DEBUG=”files” && ./KDevelop-5.0.1-x86_64.AppImage which is :

Let me tell you that I tried the same appimage with Arch and worked right away. Also I haven't had any problem with AppImage version 5.0.0-1. Just this 5.0.1 version.

So what is missing? Should I provide more debug-info about the system-installed KDevelop?

Reproducible: Always

Steps to Reproduce:
1. download from http://files.svenbrauch.de/kdevelop-linux/KDevelop-5.0.1-x86_64.AppImage
2. make the appimage executable and run it
3. crash

Actual Results:  
kdevelop: symbol lookup error: /usr/lib64/libxcb-dri3.so.0: undefined symbol: xcb_send_request_with_fds

Expected Results:  
Launch the application

I am using software compiled with -ggdb and splitdebug for proper bug reporting. Don't think it matters to the problem though.
Comment 1 Petros 2016-09-20 14:38:46 UTC

Here there is the output of LD_DEBUG="symbols" ./KDevelop-5.0.1-x86_64.AppImage
Comment 2 Sven Brauch 2016-09-20 16:29:13 UTC
Thanks a lot for this info. I think the interesting line is this:

      5970:     file=libxcb-dri3.so.0 [0];  needed by /usr/lib64/libGL.so.1 [0]

and that is the only thing which needs it, and conversely the only thing which can look up symbols in it (and fail), or am I wrong here?

libGL.so.0 is taken from your system (as it should be), and thus your versions of libGL and libxcb-dri3.so seem to be binary incompatible. Can you please rebuild them both?
Comment 3 Petros 2016-09-20 18:39:59 UTC
Portage reemerged libxcb, mesa and last xorg-server with this specific order but the problem persists.

equery b libGL.so  
 * Searching for libGL.so.1 ... 
dev-util/apitrace-7.1 (/usr/lib64/apitrace/wrappers/libGL.so.1 -> glxtrace.so)
media-libs/mesa-12.0.3 (/usr/lib32/libGL.so.1 -> libGL.so.1.2.0)
media-libs/mesa-12.0.3 (/usr/lib64/libGL.so.1 -> libGL.so.1.2.0)
media-libs/mesa-12.0.3 (/usr/lib64/libGL.so.1.2.0)

file libGL.so.1
libGL.so.1: symbolic link to libGL.so.1.2.0

file libxcb-dri3.so.0
libxcb-dri3.so.0: symbolic link to libxcb-dri3.so.0.0.0

file libxcb-dri3.so.0.0.0
libxcb-dri3.so.0.0.0: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, stripped

At first I though that there had to be some kind of inconsistency with the naming scheme of the symlinks. But every symlink exists and points where it should be. 

Below I provide the LD_DEBUG outputs relevanto dri3 from these two appimages (5.0.0-1 and 5.0.1)

LD_DEBUG="files" ./kdevelop-latest.AppImage 2>&1 | tee | grep xcb-dri3
     11109:     file=libxcb-dri3.so.0 [0];  needed by /usr/lib64/libGL.so.1 [0]
     11109:     file=libxcb-dri3.so.0 [0];  generating link map
     11109:     calling init: /usr/lib64/libxcb-dri3.so.0
     11132:     file=libxcb-dri3.so.0 [0];  needed by /usr/lib64/libGL.so.1 [0]
     11132:     file=libxcb-dri3.so.0 [0];  generating link map
     11132:     calling init: /usr/lib64/libxcb-dri3.so.0
     11135:     file=libxcb-dri3.so.0 [0];  needed by /usr/lib64/libGL.so.1 [0]
     11135:     file=libxcb-dri3.so.0 [0];  generating link map
     11135:     calling init: /usr/lib64/libxcb-dri3.so.0
     11109:     calling fini: /usr/lib64/libxcb-dri3.so.0 [0]
     11135:     calling fini: /usr/lib64/libxcb-dri3.so.0 [0]
     11132:     calling fini: /usr/lib64/libxcb-dri3.so.0 [0]
the whole output (  https://paste.pound-python.org/show/tvVFadlzvxdsYVOHwFv9/ )

LD_DEBUG="files" ./KDevelop-5.0.1-x86_64.AppImage 2>&1 | tee | grep xcb-dri
     11225:     file=libxcb-dri3.so.0 [0];  needed by /usr/lib64/libGL.so.1 [0]
     11225:     file=libxcb-dri3.so.0 [0];  generating link map
     11225:     /usr/lib64/libxcb-dri3.so.0: error: symbol lookup error: undefined symbol: xcb_send_request_with_fds (fatal)
kdevelop: symbol lookup error: /usr/lib64/libxcb-dri3.so.0: undefined symbol: xcb_send_request_with_fds

And system-installed kdevelop:
LD_DEBUG="files" /usr/bin/kdevelop
     12432:     file=libxcb-dri3.so.0 [0];  needed by /usr/lib64/libGL.so.1 [0]
     12432:EBUG=file=libxcb-dri3.so.0 [0];  generating link map
     12432:EBUG=calling init: /usr/lib64/libxcb-dri3.so.0
     12440:     file=libxcb-dri3.so.0 [0];  needed by /usr/lib64/libEGL.so.1 [0]
     12440:     file=libxcb-dri3.so.0 [0];  generating link map
     12440:     calling init: /usr/lib64/libxcb-dri3.so.0

The same command, with the same (in some way) executables, and the same (?) libraries provided. Why there is this inconsistency in the behavior?

PS I even tried to recompile libxcb, mesa and xorg without -ggdb, but of course this wasn't an issue.

PS1. I tried to create the output of LD_DEBUG="all" for the 5.0.0-1 version, but soon enough the log size was over 170MB. No way this thing can be uploaded with my internet connection. If it is necessary though, let me know.
Comment 4 Sven Brauch 2016-10-02 08:18:00 UTC
Hmm. Thanks for the information. I really can't see what could be wrong from our side :/
I think I'll let this rest unless at least one or two other users can reproduce the same problem, I think the risk of wasting time hunting a bug on our side which isn't one is too high here. Sorry.
Comment 5 rjwgnr27 2017-01-18 01:07:25 UTC
I am seeing this too, using the 5.1 Beta (KDevelop-5.0.80-x86_64.AppImage), running on a Fedora 25 system. This worked fine on another (Fedora 24) system. Libxcb on F24 is version 1.11.1; and 1.12 for F25.

I'm attaching the output file from a 'LD_DEBUG="symbols"' run, if that helps. 

Let me know if there is something else I should try, or other information which can help. From the testing I was able to do, I really want this version!
Comment 6 rjwgnr27 2017-01-18 01:10:18 UTC
Created attachment 103472 [details]
LD_DEBUG="symbols" ./KDevelop-5.0.80-x86_64.AppImage

Output from trying 'LD_DEBUG="symbols" ./KDevelop-5.0.80-x86_64.AppImage' on Fedora 25.
Comment 7 Sven Brauch 2017-01-18 08:08:54 UTC
It seems like we ship libxcb-dri2.so already, so I'll include libxcb-dri3.so as well in 5.0.4 and 5.0.81 and we can test if that works better for you. Maybe that's the reason.
Comment 8 rjwgnr27 2017-01-30 22:40:09 UTC
I personally got around the issue by building from source, by modifying the Fedora source RPMS.

But I will certainly test out 5.0.81 when it's available.
Comment 9 Björge Dijkstra 2017-02-03 18:57:27 UTC
I ran into same issue on solus linux. The missing symbol xcb_send_request_with_fds is provided by the system libxcb.so.1 library. The AppImage has its own copy of this library which overrides the system one and thus symbol cannot be found.

I worked around it by extracting the AppImage contents to a directory and replaced the usr/lib64/libxcb.so.1 with the system version. After that I can run Kdevelop by launching AppRun manually.
Comment 10 probono 2018-12-27 22:05:06 UTC
The libraries listed on https://github.com/AppImage/pkg2appimage/blob/master/excludelist should not be bundled inside AppImages.