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.
https://paste.pound-python.org/show/qWSBxLxUpD7ixgSIMIy6/ Here there is the output of LD_DEBUG="symbols" ./KDevelop-5.0.1-x86_64.AppImage
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?
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 ^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.
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.
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!
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.
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.
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.
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.
The libraries listed on https://github.com/AppImage/pkg2appimage/blob/master/excludelist should not be bundled inside AppImages.