[Mesa-dev] [Bug 59879] reducing symbol visibility of shared objects / static libstdc++

[bugzilla-daemon at freedesktop.org]

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

José Fonseca <jfonseca at vmware.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jfonseca at vmware.com

--- Comment #1 from José Fonseca <jfonseca at vmware.com> ---
(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...

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