On 11/03/15 16: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.
FWIW, here are NVIDIA OpenGL driver dependencies:
$ ldd -r /usr/lib/nvidia-331-updates/libGL.so.1
/usr/lib/nvidia-331-updates/tls/libnvidia-tls.so.331.113
/usr/lib/nvidia-331-updates/libnvidia-glcore.so.331.113
/usr/lib/nvidia-331-updates/libGL.so.1:
linux-vdso.so.1 => (0x00007fff5cbfc000)
libnvidia-tls.so.331.113 =>
/usr/lib/nvidia-331-updates/tls/libnvidia-tls.so.331.113
(0x00007fa64be1f000)
libnvidia-glcore.so.331.113 =>
/usr/lib/nvidia-331-updates/libnvidia-glcore.so.331.113 (0x00007fa649610000)
libX11.so.6 => /usr/lib/x86_64-linux-gnu/libX11.so.6
(0x00007fa6492d6000)
libXext.so.6 => /usr/lib/x86_64-linux-gnu/libXext.so.6
(0x00007fa6490c4000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fa648cff000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fa648afa000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fa6487f4000)
libxcb.so.1 => /usr/lib/x86_64-linux-gnu/libxcb.so.1
(0x00007fa6485d5000)
/lib64/ld-linux-x86-64.so.2 (0x00007fa64c37e000)
libXau.so.6 => /usr/lib/x86_64-linux-gnu/libXau.so.6
(0x00007fa6483d0000)
libXdmcp.so.6 => /usr/lib/x86_64-linux-gnu/libXdmcp.so.6
(0x00007fa6481ca000)
/usr/lib/nvidia-331-updates/tls/libnvidia-tls.so.331.113:
linux-vdso.so.1 => (0x00007fff4d9fc000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f9a55f90000)
/lib64/ld-linux-x86-64.so.2 (0x00007f9a56581000)
/usr/lib/nvidia-331-updates/libnvidia-glcore.so.331.113:
linux-vdso.so.1 => (0x00007fff97f3c000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f1b8d064000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f1b8cc9f000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f1b8ca9a000)
/lib64/ld-linux-x86-64.so.2 (0x00007f1b8fba2000)
I can almost bet that NVIDIA uses C++ somewhere, but no dependencies on
libstdc++. Not sure if they chose to statically link libstdc++ to
support multiple distros, or to avoid issues like applications shipping
their own libstdc++...
Jose
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
