On 11.03.2015 17:01, Francisco Jerez wrote:
Vivek Dasmohapatra <vi...@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 problem in not forcing this to link statically is, that if a
distribution decides to not use this static option, the problem persists
on that distribution. On top every lib pulled in by steam from the
system would need to be link statically, like mesa. Instead of fixing
every lib steam pulls in (how many are there?), fix the steam runtime to
a) not ship libstdc++.so and libgcc_s.so and declare older version of
these libs as not supported (thats what people do when they face the
incompatibility problem with steams versions of these libs: just delete
them from the runtime and everything is fine)
b) ship own mesa and libdrm drivers
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
[...]
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
