| Summary: | reducing symbol visibility of shared objects / static libstdc++ | ||
|---|---|---|---|
| Product: | Mesa | Reporter: | Tobias Jakobi <liquid.acid> |
| Component: | Mesa core | Assignee: | mesa-dev |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | medium | CC: | jfonseca |
| Version: | unspecified | ||
| Hardware: | x86-64 (AMD64) | ||
| OS: | Linux (All) | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
|
Description
Tobias Jakobi
2013-01-26 01:29:59 UTC
(In reply to comment #0) > Hello, > > this is sort of cleaned up report of bug #37637. > > To quickly summarize what happens there: Build r600g with the llvm compiler > backend and try starting ut2003. Segfault happens since apparantly ut's > engine has a version of libstdc++ built in, which now clashes with the > libstdc++ shared lib which either r600_dri.so or LLVM (when build as shared) > loads. This is independent of preloading order. When the symbols from the > system libstdc++ take preference, then the game engine crashes. When the > game engine symbols take preference, the r600g driver initialization crashes. > > The fix for the problem: Since we can't modify the ut2003 binary, we have to > hide the "duplicate" symbols somehow. > > This means: > - build r600g with static llvm > - build r600 with static libstdc++ [...] > What I'm struggling with is properly telling autotools to build a shared lib with static libstdc++. The gcc manpage mentions an option called "-static-libstdc++", but it doesn't seem to have any effect. AFAIK, -static-libstdc++ allows one to statically link libstdc++ to an _executable_, not to a dynamic library (as it lacks -fPIC). I see two ways of achieving this: - have our own custom build of libstdc++ where we build a static library of libstdc++.a with -fPIC. - statically link (w/ -Bsymbolic) against stubs of libstdc++ symbols, where each stub does dlsym(dlopen('/usr/lib32/libstdc++.so.6', RTLD_LOCAL), "foo") FWIW, either seem a lot of work just for sake of an old binary-only game. The ideal would be for UT to rely on distro's libstdc++ instead of its own version... Ignore the "lib32" above. I meant "lib" The issue here is that while -static-libstdc++ should work for both executables and libraries and gcc is smart enough to understand it, libtool is not :\ The latter essentially ignores the switch and always explicitly appends "-lstdc++". Thus even adding "-Wl,-Bstatic -lstdc++ -Wl,-Bdynamic" to our linker flags (inside the makefiles) will not work, as those come prior to "-lstdc++". I fear that someone familiar with libtool will need to fix it... that or we can nuke the c++ code from mesa xD Either way, at least the symbol visibility is resolved has been fixed with recent mesa :) Closing this since I no longer own a system where the AMD GPU relies on r600g. On my current radeonsi system the ut2003 issue doesn't appear, so I guess the visibility fixes mentioned by Emil have fixes this one as well. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.