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

[Francisco Jerez]

Ian Romanick <idr at freedesktop.org> writes:

> 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."
>
> 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."

That's why the GNU C++ runtime uses library and symbol versioning to
allow ABI-incompatible versions to coexist.  It would be possible for
Steam to provide a "reference" version of the C++ runtime that would be
used in cases where either the operating system version is too old (in
which case other libraries from the OS linking to a libstdc++ with same
SONAME are guaranteed to be forwards-compatible with Steam's), or in
cases where the operating system version is so new that it's
ABI-incompatible with Steam's (in which case it would be possible for
both versions to coexist thanks to symbol versioning so pulling
libraries from the OS wouldn't pose a problem).  In all other cases they
ought to be using the C++ runtime from the operating system if they
don't want to distribute their own libGL...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 212 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20150311/8896c717/attachment-0001.sig>