<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#c6">Comment # 6</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#c5">comment #5</a>) > 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 <a href="show_bug.cgi?id=93103#c2">comment 2</a> - 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.</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>