https://bugs.kde.org/show_bug.cgi?id=369105
--- Comment #3 from Petros <petross...@gmail.com> ---
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.
--
You are receiving this mail because:
You are watching all bug changes.
