<html> <head> <base href="https://bugs.freedesktop.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - llvm symbols leak through, cause trouble with software rendering in llvm-linked software" href="https://bugs.freedesktop.org/show_bug.cgi?id=93103#c12">Comment # 12</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - llvm symbols leak through, cause trouble with software rendering in llvm-linked software" href="https://bugs.freedesktop.org/show_bug.cgi?id=93103">bug 93103</a> from <a class="email" href="mailto:emil.l.velikov@gmail.com" title="Emil Velikov <emil.l.velikov@gmail.com>"> Emil Velikov</a> <pre>(In reply to Tobias Schlüter from <a href="show_bug.cgi?id=93103#c10">comment #10</a>) > 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 > libglapi.so.0 => /usr/lib/x86_64-linux-gnu/libglapi.so.0 Based on this I'd say > (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: Glad to hear. > 1) I wouldn't consider it good practice to redefine LLVM as a "system > library" and then blame problems related to it on users In my view once any library is installed system wide it can be considered "system". As to who and why did that is not a another question for me to answer ;-) > 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) > That plus the possible RTLD_GLOBAL issue. On the good side I should be looking into our end soonish. > 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). Great, good luck (in an honest, non sarcastic way).</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the QA Contact for the bug.</li> <li>You are the assignee for the bug.</li> </ul> </body> </html>