[Mesa-dev] Statically linking libstdc++ and libgcc

[Francisco Jerez]

Vivek Dasmohapatra <vivek at collabora.co.uk> writes:

> Hi -

Hi,

> As you probably already know, there can only be one version of
> libstdc++.so in your runtime link chain

That's a common misconception, in principle several versions of
libstdc++.so with different DT_SONAME (i.e. with mutually incompatible
ABIs) can be loaded at the same time, the GNU C++ runtime uses library
and symbol versioning to achieve this.  Of course two different versions
with the same DT_SONAME cannot coexist, but that's not supposed to pose
a problem because applications linked to the earlier version are
expected to be forwards-compatible with more recent minor versions of
the standard library.  See [1].

> This is usually not a problem, but when things are linked against the
> Steam runtime (for example), they can end up with two - one from the
> steam runtime, and one pulled in via the mesa dri libs from the
> OS/distribution.
>
Last time I looked into this, it seemed to be a logical consequence of
the inconsistency of the Steam runtime overriding system libraries: If
they go as far as to override the operating system's copy of the C++
standard library and runtime with an outdated version (even though the
OS libraries with the same DT_SONAME are expected to be
backwards-compatible with Steam's), they should be shipping their own
builds of libGL and DRI drivers as well.

> In order to address this, Valve asked Collabora to look at enabling
> mesa linking with libstdcc+.a/libgcc.a/libgcc_eh.a instead of
> listdcc++so and libgcc_s.so.
>
> I think I've figured out a minimally intrusive way to do this, working
> around the fact that libtool really, really wants to link those in
> if C++ is involved.
>
> I've broken this up into a couple of pieces:
>
> The first patch attached gets libtool to not link in the .so
> files in question: It's pretty small - it doesn't introduce a
> configure flag to control this behaviour, but I would be happy
> to adapt it to do so if that's considered a better approach.
>
Honestly, I think that statically linking the C++ runtime is a hack, and
it should be an opt-in based on some configure option if we want to
support it at all.

> The second and third extend this a little further: Patch #3
> is actually to llvm, and builds a parallel libLLVM-X.Y-nostdlib.so
> which is likewise linked with libstdc++.a et al instead of .so,
> and patch #2 makes the mesa build system use said library if it
> is available.
>
> So: Would mesa be interested in patches #1 and/or #2?
> If not, is there something I could do to make the patches
> more palatable, or some other approach that you'd prefer?
>
> ( I'm aware of the configure flags to statically link against
>    libLLVM, but when I tried it with llvm-3.5 and a git checkout
>    of mesa 10.6-dev I got link errors, hence the LLVM patchset. )

[1] https://gcc.gnu.org/onlinedocs/libstdc++/manual/abi.html

>[...]
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 212 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20150311/547aef00/attachment.sig>