Bug 369105

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.