https://bugs.freedesktop.org/show_bug.cgi?id=93103
--- Comment #9 from Jose Fonseca <jfons...@vmware.com> --- (In reply to Emil Velikov from comment #6) > Check, if ever in doubt about the exposed symbols. > > libGL itself > $ nm -CD --defined-only /lib/libGL.so | grep -v " gl" [...] > > DRI module, used by libGL (do check all the "*_dri.so" found in /lib) > $ nm -CD --defined-only /lib/xorg/modules/dri/swrast_dri.so [...] > > As you can see, nothing from LLVM/Clang is explicitly exported/leaked. My understanding from Tobias description is that the LLVM symbols from /usr/lib/x86_64-linux-gnu/libLLVM-3.6.so.1 are clashing with a custom LLVM build for cling -- https://root.cern.ch/cling-build-instructions The real question is what symbols libLLVM-3.6.so provides, and $ nm -CD --defined-only /usr/lib/x86_64-linux-gnu/libLLVM-3.6.so.1 shows lot of them. LLVM is used in lots of projects nowadays -- language interpreters, etc. So are OpenGL drivers -- they get loaded in all sort of processes. So when distro decided to use a shared LLVM for the opengl drivers to save a few bytes, they basically gave the finger to everybody who needs to use bleeding edge LLVM and OpenGL... (In reply to Emil Velikov from comment #3) > > In addition to that, we probably also need to use a LD version script to > > ensure that LLVM symbols don't pop in the dynamic symbol table. > We have those for a while. I'm not sure it helps if the problem is is /usr/lib/x86_64-linux-gnu/libLLVM-3.4.so.1 . The only solution is if the system libLLVM-X.X.so an unique symbol version/namespace, or maybe the RTLD_LOCAL as you mentioned. > Atm only the autotools build uses them (hint hint > scons). Sure. I'll look into it. -- 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
