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

[Michel Dänzer]

On 13.03.2015 03:07, Pierre-Loup A. Griffais wrote:
> On 03/11/2015 09:40 AM, Ian Romanick wrote:
>> On 03/11/2015 09:31 AM, Tobias Klausmann wrote:
>>> 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
>>
>> Yeah, static linking is a terrible, partial solution.
>>
>>> 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)
>>
>> Let's be 100% clear.  This is NOT an option for Steam.  They ship
>> thousands of closed-source applications.  These applications were built
>> and tested against specific versions of specific libraries.  Removing
>> support for old run-times is equivalent to removing support for those
>> applications.  They can't tell their customers, "You upgraded your
>> distro, so that game you paid money for no longer works.  Tough break,
>> kid."
> 
> Quite true; developers build and test their games against this known set
> of libraries through the Steam Runtime toolchain. Expecting them to
> manage all of their dependencies (through bundling or static linking) is
> unreasonable; all other platforms they're used to dealing with solve
> this problem one way or another. Admittedly the current implementation
> of the Steam runtime is only a first step towards providing a solution,
> and some things could be done better, but this issue will stand regardless.
> 
> The C++ runtime is a very complex beast and swapping it under an
> application that makes heavy use of it is prone to failure. We'll keep
> running games against the C++ runtime of the SDK version they were built
> against, forever.
> 
> The LLVM-enabled variants of Mesa are the only implementations where
> this is an issue; this is actually causing affected users in the wild to
> switch to the Catalyst driver, since it (along with all others) goes out
> of its way to avoid this specific problem for this exact reason.
> 
> Their only other option is to slam the whole Steam runtime off, which
> breaks a lot of games outright because they depend on some library that
> recent distros don't ship anymore, or moved to the new major version.

In my experience, and from other reports I've seen, simply deleting
libstdc++ / libgcc from the Steam runtime works just fine. This shows
that a) the problem is that Steam overrides the system versions of these
libraries with older versions, b) doing that isn't necessary, as the
games work just fine with the newer system versions of these libraries,
since they preserve backwards compatibility.

So, a simple solution would be for Steam not to override these
libraries[0] when the system already has the same or newer versions of
them available. That doesn't require deviating from long established
best practices for building and distributing software in distros.

[0] Note that "these libraries" refers to the specific SONAMEs, e.g.
libstdc++.so.6 and libgcc_s.so.1. If the system only provides different
SONAMEs for these libraries, it should be fine for Steam to use its own
versions of these SONAMEs.


-- 
Earthling Michel Dänzer               |               http://www.amd.com
Libre software enthusiast             |             Mesa and X developer