https://bugs.freedesktop.org/show_bug.cgi?id=93103
--- Comment #10 from Tobias Schlüter <t...@schlueters.de> ---
Probably no longer relevant per #8, and I don't know how to tell different
libGL.so.1 apart with certainty, but I guess you can do this based on ldd
output, so here goes (DRI appears, Xlib doesn't):
$ ldd /usr/lib/x86_64-linux-gnu/mesa/libGL.so
linux-vdso.so.1 => (0x00007ffe71b89000)
libglapi.so.0 => /usr/lib/x86_64-linux-gnu/libglapi.so.0
(0x00007f118cf53000)
libXext.so.6 => /usr/lib/x86_64-linux-gnu/libXext.so.6 (0x00007f118cd41000)
libXdamage.so.1 => /usr/lib/x86_64-linux-gnu/libXdamage.so.1
(0x00007f118cb3e000)
libXfixes.so.3 => /usr/lib/x86_64-linux-gnu/libXfixes.so.3
(0x00007f118c938000)
libX11-xcb.so.1 => /usr/lib/x86_64-linux-gnu/libX11-xcb.so.1
(0x00007f118c736000)
libX11.so.6 => /usr/lib/x86_64-linux-gnu/libX11.so.6 (0x00007f118c401000)
libxcb-glx.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-glx.so.0
(0x00007f118c1ea000)
libxcb-dri2.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-dri2.so.0
(0x00007f118bfe5000)
libxcb-dri3.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-dri3.so.0
(0x00007f118bde2000)
libxcb-present.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-present.so.0
(0x00007f118bbdf000)
libxcb-sync.so.1 => /usr/lib/x86_64-linux-gnu/libxcb-sync.so.1
(0x00007f118b9d9000)
libxcb.so.1 => /usr/lib/x86_64-linux-gnu/libxcb.so.1 (0x00007f118b7ba000)
libxshmfence.so.1 => /usr/lib/x86_64-linux-gnu/libxshmfence.so.1
(0x00007f118b5b8000)
libXxf86vm.so.1 => /usr/lib/x86_64-linux-gnu/libXxf86vm.so.1
(0x00007f118b3b2000)
libdrm.so.2 => /usr/lib/x86_64-linux-gnu/libdrm.so.2 (0x00007f118b1a6000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
(0x00007f118af88000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f118ad84000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f118a9bf000)
libXau.so.6 => /usr/lib/x86_64-linux-gnu/libXau.so.6 (0x00007f118a7bb000)
libXdmcp.so.6 => /usr/lib/x86_64-linux-gnu/libXdmcp.so.6
(0x00007f118a5b5000)
/lib64/ld-linux-x86-64.so.2 (0x00007f118d3e0000)
$
Concerning #6, from which I learnt a lot, thank you for that, two comments:
1) I wouldn't consider it good practice to redefine LLVM as a "system library"
and then blame problems related to it on users
2) I guess I could read your comment as saying that the bug lies with LLVM as
they (at least up to version 3.6) don't version their symbols correct (though
from a user-experience side there is an issue with libmesa, even if it is
inherited)
I have pointed the ROOT people to this bug report, I hope they can draw their
conclusions from this. We're currently setting up mesa 11 and the latest
version of ROOT, and I will report back.
ps concerning the choices about who should statically link, I agree with #9
(submitted while I was putting this comment together).
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
