Update libstdc++.so.6.18 -> libstdc++.so.6.20

[nanonyme]

Hey,
please update libstdc++. This should make Steam work out of the box for open drivers again for people with newer distributions. Insofar as I've understood should be without downsides as no ABI breakage.

[sylware]

c++ ABI is hell on earth. The reasonable thing to do is to statically link libstdc++ into the runtime (same thing would apply to libgcc) and let games statically link theirs.
More over, it's compiler/runtime specific. It's so hard to get right, there is near 0 "ok" c++ compiler/runtime for "production".
And look how hard and long it is to code an alternative (clang).
c++ is not something sane.

[nanonyme]

Well, I'd also be happy if this libstdc++ was removed from Steam runtime but for some reason unknown to me Steam wants to ship it so I'm at requesting that at least a non-obsolete version is shipped.

[sylware]

I think it's a good thing to keep libstdc++ in the runtime. But game devs should be directed to statically link their libstdc++ in their binaries (and libgcc too).
Since gcc 4.7 it's 2 gcc command line options, then super ultra easy to add.
Keeping that lib in the runtime is a kind of guardian against "you don't have the latest c++ ABI/feature on your gnu/linux system then your game won't run". The libc/GL/x11/alsa system libs are already too much and they rely on simple C entry points. Let me guess what will happen on the medium term with a libstdc++ which evolves super fast due to the current c++ standardisation body fenzy. With the insanity of the c++ ABI... it's unreasonnable. Moreover maybe clang c++ ABI will diverge from the gcc c++ ABI (or be just unable to be really compatible since it's hell on earth). BTW, no idea of intel c++ ABI direction.

IMHO, the right way:

• keep the shared libstdc++ into the runtime
• statically link steam client/runtime with libstdc++ (and libgcc)
• direct games devs to statically link their games as much as they can
  But the end decision belongs to valve technical management staff.

[mbabuskov]

@sylware care to say which two command line options? Thanks.

[sylware]

https://gcc.gnu.org/onlinedocs/gcc/Link-Options.html#Link-Options
static-libgcc ... there is an application for c++ apps too, like static
libstdc++

On Sun, Oct 16, 2016 at 7:57 AM, mbabuskov notifications@github.com wrote:

@sylware https://github.com/sylware care to say which two command line
options? Thanks.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#31 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAOBJKjRCrQTGoJhzadZTeGcltr7lLhJks5q0hEQgaJpZM4DyQMz
.

[nanonyme]

@sylware yes, I totally agree games should staticly link against libstdc++.
Please, Valve, make that an official recommendation if not a requirement to all future games. It will save tons of maintenance time.

[sylware]

and libgcc...

[sylware]

To make things sharper: the near-ultimate/definitive solution is to depend only on the elf interpreter/libdl to dynamically load the input/sound/3D|windowing/networking system specific libs with their confs and dependencies into the steam client and game processes while minimizing interferences with what's already installed on the system. Everything else could make direct linux syscalls as statically linked code (for instance threading related code). Try to break this... and that would allow alternative elf interpreters and dynamic loaders to work (the important thing is to rely only on basic symbol resolving, no elf version or any elf complex stuff). This can be achieved in a carefully crafted SDK with proper guidelines. libSDL seems to be a significant part of the solution, even adding cross-platform sugar. Bigger exes, but super Godly robust exes. In reality, it is not easily possible to create dynamic binaries which can run on a musl lib system or a gnu glibc system due to many libc runtime specific symbols and shared internals. You would need a SDK switch to compile a gnu glibc exe or a musl lib exe (this is sad).