|Summary:||KDevelop-5.0.1 AppImage doesn't launch on Gentoo because of "libxcb-dri3.so.0: error: symbol lookup error"|
|Product:||[Applications] kdevelop||Reporter:||Petros <petross404>|
|Component:||general||Assignee:||Sven Brauch <mail>|
|Severity:||normal||CC:||bdijkstra, mail, probono, rjwgnr27|
|Latest Commit:||Version Fixed In:|
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: http://files.svenbrauch.de/kdevelop-linux/ 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 : https://paste.pound-python.org/show/I3u5A2gfeoDAm8VaNnah/ 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
https://paste.pound-python.org/show/qWSBxLxUpD7ixgSIMIy6/ 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 ; needed by /usr/lib64/libGL.so.1  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 ; needed by /usr/lib64/libGL.so.1  11109: file=libxcb-dri3.so.0 ; generating link map 11109: calling init: /usr/lib64/libxcb-dri3.so.0 11132: file=libxcb-dri3.so.0 ; needed by /usr/lib64/libGL.so.1  11132: file=libxcb-dri3.so.0 ; generating link map 11132: calling init: /usr/lib64/libxcb-dri3.so.0 11135: file=libxcb-dri3.so.0 ; needed by /usr/lib64/libGL.so.1  11135: file=libxcb-dri3.so.0 ; generating link map 11135: calling init: /usr/lib64/libxcb-dri3.so.0 11109: calling fini: /usr/lib64/libxcb-dri3.so.0  11135: calling fini: /usr/lib64/libxcb-dri3.so.0  11132: calling fini: /usr/lib64/libxcb-dri3.so.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 ; needed by /usr/lib64/libGL.so.1  11225: file=libxcb-dri3.so.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 ; needed by /usr/lib64/libGL.so.1  12432:EBUG=file=libxcb-dri3.so.0 ; generating link map 12432:EBUG=calling init: /usr/lib64/libxcb-dri3.so.0 12440: file=libxcb-dri3.so.0 ; needed by /usr/lib64/libEGL.so.1  12440: file=libxcb-dri3.so.0 ; generating link map 12440: calling init: /usr/lib64/libxcb-dri3.so.0 ^C 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.