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

[bugzilla-daemon at freedesktop.org]

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

          Priority: medium
            Bug ID: 59879
          Assignee: mesa-dev at lists.freedesktop.org
           Summary: reducing symbol visibility of shared objects / static
                    libstdc++
          Severity: normal
    Classification: Unclassified
                OS: Linux (All)
          Reporter: liquid.acid at gmx.net
          Hardware: x86-64 (AMD64)
            Status: NEW
           Version: unspecified
         Component: Mesa core
           Product: Mesa

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++
- 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:
http://sourceware.org/binutils/docs-2.21/ld/VERSION.html#VERSION

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:
http://www.gnu.org/software/gnulib/manual/html_node/LD-Version-Scripts.html

----------------------------


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

-- 
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/20130126/bf5dfae4/attachment-0001.html>