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

Reply via email to