<html>
<head>
<base href="https://bugs.freedesktop.org/" />
</head>
<body><table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>Priority</th>
<td>medium
</td>
</tr>
<tr>
<th>Bug ID</th>
<td><a class="bz_bug_link
bz_status_NEW "
title="NEW --- - reducing symbol visibility of shared objects / static libstdc++"
href="https://bugs.freedesktop.org/show_bug.cgi?id=59879">59879</a>
</td>
</tr>
<tr>
<th>Assignee</th>
<td>mesa-dev@lists.freedesktop.org
</td>
</tr>
<tr>
<th>Summary</th>
<td>reducing symbol visibility of shared objects / static libstdc++
</td>
</tr>
<tr>
<th>Severity</th>
<td>normal
</td>
</tr>
<tr>
<th>Classification</th>
<td>Unclassified
</td>
</tr>
<tr>
<th>OS</th>
<td>Linux (All)
</td>
</tr>
<tr>
<th>Reporter</th>
<td>liquid.acid@gmx.net
</td>
</tr>
<tr>
<th>Hardware</th>
<td>x86-64 (AMD64)
</td>
</tr>
<tr>
<th>Status</th>
<td>NEW
</td>
</tr>
<tr>
<th>Version</th>
<td>unspecified
</td>
</tr>
<tr>
<th>Component</th>
<td>Mesa core
</td>
</tr>
<tr>
<th>Product</th>
<td>Mesa
</td>
</tr></table>
<p>
<div>
<pre>Hello,
this is sort of cleaned up report of <a class="bz_bug_link
bz_status_REOPENED "
title="REOPENED --- - unreal tournament crashes with mesa 7.11-dev"
href="show_bug.cgi?id=37637">bug #37637</a>.
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++
- only make those symbols in r600_dri.so visible which are necessary
Building r600g with static llvm is trivial. The symbol visibility can be
properly handled by ld:
<a href="http://sourceware.org/binutils/docs-2.21/ld/VERSION.html#VERSION">http://sourceware.org/binutils/docs-2.21/ld/VERSION.html#VERSION</a>
My current dri-symbols.map:
{
global: __dri*; dri*; _glapi*;
local: *;
};
This hides everything except for the symbols matching __dri*, dri* and _glapi*.
This can be potentially reduced even further. However it's not clear to me what
the loader code in libGL really needs.
This version-script'ing can be properly put into autotools language:
<a href="http://www.gnu.org/software/gnulib/manual/html_node/LD-Version-Scripts.html">http://www.gnu.org/software/gnulib/manual/html_node/LD-Version-Scripts.html</a>
----------------------------
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.
Let's look at the critical calls (I've shortened them somewhat):
OK, we're in src/gallium/targets/dri-r600. The last libtool call that the
Makefile executes is the following one:
bin/sh ../../../../libtool --tag=CXX --mode=link g++ -g -O2 -Wall
-fno-strict-aliasing -fno-builtin-memcmp -module -avoid-version -shared
-no-undefined
-Wl,--version-script=../../../../src/gallium/targets/dri-symbols.map
-L/usr/lib64/llvm -lpthread -lffi -ldl -lm -o r600_dri.la -rpath
/usr/local/lib/dri target.lo utils.lo dri_util.lo xmlconfig.lo <libtool files>
-ldrm -lexpat -lm -lrt -lpthread -ldl -ldrm -ldrm_radeon <llvm libs>
libtool itself produces this call from it:
g++ -fPIC -DPIC -shared -nostdlib <some object files> -Wl,--whole-archive <the
archives> -Wl,--no-whole-archive -L/usr/lib64/llvm <llvm libs part 1> -lexpat
-lrt -lpthread -ldl -ldrm -ldrm_radeon <llvm libs part 2>
-L/usr/lib/gcc/x86_64-pc-linux-gnu/4.7.2
-L/usr/lib/gcc/x86_64-pc-linux-gnu/4.7.2/../../../../lib64 -L/lib/../lib64
-L/usr/lib/../lib64
-L/usr/lib/gcc/x86_64-pc-linux-gnu/4.7.2/../../../../x86_64-pc-linux-gnu/lib
-L/usr/lib/gcc/x86_64-pc-linux-gnu/4.7.2/../../.. -lstdc++ -lm -lc -lgcc_s
<more object files> -O2
-Wl,--version-script=../../../../src/gallium/targets/dri-symbols.map
-Wl,-soname -Wl,r600_dri.so -o .libs/r600_dri.so
Notice the "-lstdc++", dynamic linking to libstdc++. What I'd like libtool (and
eventually autotools) to produce is the following:
g++ -fPIC -DPIC -shared -nostdlib <some object files> -Wl,-Bstatic -lstdc++
-Wl,-Bdynamic -Wl,--whole-archive <the archives> -Wl,--no-whole-archive
-L/usr/lib64/llvm <llvm libs part 1> -lexpat -lrt -lpthread -ldl -ldrm
-ldrm_radeon <llvm libs part 2> -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.7.2
-L/usr/lib/gcc/x86_64-pc-linux-gnu/4.7.2/../../../../lib64 -L/lib/../lib64
-L/usr/lib/../lib64
-L/usr/lib/gcc/x86_64-pc-linux-gnu/4.7.2/../../../../x86_64-pc-linux-gnu/lib
-L/usr/lib/gcc/x86_64-pc-linux-gnu/4.7.2/../../.. -lm -lc -lgcc_s <more object
files> -O2 -Wl,--version-script=../../../../src/gallium/targets/dri-symbols.map
-Wl,-soname -Wl,r600_dri.so -o .libs/r600_dri.so
This is just removing "-lstdc++" and replacing it by "-Wl,-Bstatic -lstdc++
-Wl,-Bdynamic" at a different position (!). Putting it in front of the archive
assembly seems to be critical.
This links fine (no warnings, etc.) and produces a .so that is loaded properly
by libGL's loader and (more importantly) works fine with ut2003.
However it is still a mystery to me how to makes this clear to either libtool
or autotools.
Greets,
Tobias</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are the assignee for the bug.</li>
</ul>
</body>
</html>