Ian Romanick <i...@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...
signature.asc
Description: PGP signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
