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

[Tobias Klausmann]

On 11.03.2015 17: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.
>

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 at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/mesa-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20150311/224d7c93/attachment-0001.html>