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

[Pierre-Loup A. Griffais]

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.

Distributions _want_ this fixed, not the other way around.

Thanks,
  - Pierre-Loup

>
> Forcing an application to use a newer run-time may work over the short
> term, but do you think that will still work in 5 years?  It's possible,
> but it seems unlikely.  And "seems to work" is not the same as "works
> all the way through the whole game every time."
>
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>