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

[Jose Fonseca]

On 11/03/15 16:01, Francisco Jerez wrote:
> 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.

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