[Mesa-dev] [Bug 93103] llvm symbols leak through, cause trouble with software rendering in llvm-linked software

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=93103

--- Comment #6 from Emil Velikov <emil.l.velikov at gmail.com> ---
(In reply to Tobias Schlüter from comment #5)
> Thank you for the quick response!  I'll take the comments to mean that this
> shouldn't happen with very recent versions of libmesa and llvm.  It does
> happen with fairly recent versions though.
> 
A "global" (affecting all drivers) version script has been added in mesa circa
10.2.

> We verified on a colleague's system that the same error appears on Ubuntu
> 15.05 with libmesa 10.5.9 and libllvm 3.6, (there are some differences in
> the backtrace because we used a slightly simpler way of triggering the bug
> as documented in the ROOT bug report I was linking to).  I would be
> surprised if Ubuntu uses scons for the build, but I don't know.

Pretty much every Linux distributions uses the autotools.

Check, if ever in doubt about the exposed symbols.

libGL itself
$ nm -CD --defined-only /lib/libGL.so | grep -v " gl"
00000000002969c8 b __bss_start
00000000002969c8 d _edata
0000000000297480 b _end
0000000000074c54 T _fini
000000000004e9d0 T _glapi_create_table_from_handle
0000000000017338 T _init


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
0000000000642e60 T amdgpu_winsys_create
0000000000a62480 B __driDriverExtensions
0000000000073510 T __driDriverGetExtensions_kms_swrast
00000000000735d0 T __driDriverGetExtensions_nouveau
00000000000735f0 T __driDriverGetExtensions_r300
0000000000073610 T __driDriverGetExtensions_r600
0000000000073630 T __driDriverGetExtensions_radeonsi
0000000000073440 T __driDriverGetExtensions_swrast
0000000000073650 T __driDriverGetExtensions_vmwgfx
00000000003fa060 T nouveau_drm_screen_create
000000000062c9b0 T radeon_drm_winsys_create

As you can see, nothing from LLVM/Clang is explicitly exported/leaked.

> 
> I don't agree with Emil that it is a problem on the ROOT side (even though
> the installed a workaround): one should be able to use libmesa without being
> afraid that symbols leak through that are not part of libmesa's public
> interface.

First and foremost I would encourage you to try with statically linked LLVM as
Jose suggested.

On the actual issue and who's "doing things wrong" it's a combination of bugs
and suboptimal decisions:

 1 To avoid pollution of (conflicts in) global namespace, people must make sure
that they hide their symbols - as done with the ROOT report. Imho this is a
must fix.

 2 Mesa should not dlopen its module with RTLD_GLOBAL. This in itself may
pollute the global namespace (haven't checked), despite that we've hidden the
exported symbols.

 3 Using private libraries conflicting(incompatible) with the system ones is a
very bad idea. If needed one can 1) static link the private ones in their
application or 2) do LD_PRELOAD/LD_LIBRARY_PATH/RPATH magic to ensure the
correct libraries are loaded.

Fixing this on the client side is trivial (both 1 and 3.1). I'm afraid that
fixing the one in mesa is a lot more convoluted than the patch in comment 2 -
we tried and quickly had to revert it :-(

Not saying that mesa is perfect - on the contrary we should drop the
RTLD_GLOBAL hack. Then again others could do their fair share in keeping things
sane.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20151126/24821ba3/attachment.html>