Problem with libstdc++.so.6 bundled with steam-runtime 2014-04-15

[jsa1983]

After a graphics drivers and llvm update (mesa git 2014.04.26, compiled with llvm 3.5; llvm 3.5 svn 207303) I have experienced the following problem:

libGL error: dlopen /usr/lib/i386-linux-gnu/dri/radeonsi_dri.so failed (/home/jose/.local/share/Steam/ubuntu12_32/steam-runtime/i386/usr/lib/i386-linux-gnu/libstdc++.so.6: version GLIBCXX_3.4.18' not found (required by /usr/lib/i386-linux-gnu/libLLVM-3.5.0.so.1)) libGL error: dlopen ${ORIGIN}/dri/radeonsi_dri.so failed (${ORIGIN}/dri/radeonsi_dri.so: no se puede abrir el archivo del objeto compartido: No existe el archivo o el directorio) libGL error: dlopen /usr/lib/dri/radeonsi_dri.so failed (/usr/lib/dri/radeonsi_dri.so: no se puede abrir el archivo del objeto compartido: No existe el archivo o el directorio) libGL error: unable to load driver: radeonsi_dri.so libGL error: driver pointer missing libGL error: failed to load driver: radeonsi libGL error: dlopen /usr/lib/i386-linux-gnu/dri/swrast_dri.so failed (/home/jose/.local/share/Steam/ubuntu12_32/steam-runtime/i386/usr/lib/i386-linux-gnu/libstdc++.so.6: versionGLIBCXX_3.4.18' not found (required by /usr/lib/i386-linux-gnu/libLLVM-3.5.0.so.1)) libGL error: dlopen ${ORIGIN}/dri/swrast_dri.so failed (${ORIGIN}/dri/swrast_dri.so: no se puede abrir el archivo del objeto compartido: No existe el archivo o el directorio) libGL error: dlopen /usr/lib/dri/swrast_dri.so failed (/usr/lib/dri/swrast_dri.so: no se puede abrir el archivo del objeto compartido: No existe el archivo o el directorio) libGL error: unable to load driver: swrast_dri.so libGL error: failed to load driver: swrast ExecCommandLine: "/home/jose/.local/share/Steam/ubuntu12_32/steam" System startup time: 8,15 seconds libGL error: dlopen /usr/lib/i386-linux-gnu/dri/radeonsi_dri.so failed (/home/jose/.local/share/Steam/ubuntu12_32/steam-runtime/i386/usr/lib/i386-linux-gnu/libstdc++.so.6: version GLIBCXX_3.4.18' not found (required by /usr/lib/i386-linux-gnu/libLLVM-3.5.0.so.1)) libGL error: dlopen ${ORIGIN}/dri/radeonsi_dri.so failed (${ORIGIN}/dri/radeonsi_dri.so: no se puede abrir el archivo del objeto compartido: No existe el archivo o el directorio) libGL error: dlopen /usr/lib/dri/radeonsi_dri.so failed (/usr/lib/dri/radeonsi_dri.so: no se puede abrir el archivo del objeto compartido: No existe el archivo o el directorio) libGL error: unable to load driver: radeonsi_dri.so libGL error: driver pointer missing libGL error: failed to load driver: radeonsi libGL error: dlopen /usr/lib/i386-linux-gnu/dri/swrast_dri.so failed (/home/jose/.local/share/Steam/ubuntu12_32/steam-runtime/i386/usr/lib/i386-linux-gnu/libstdc++.so.6: versionGLIBCXX_3.4.18' not found (required by /usr/lib/i386-linux-gnu/libLLVM-3.5.0.so.1)) libGL error: dlopen ${ORIGIN}/dri/swrast_dri.so failed (${ORIGIN}/dri/swrast_dri.so: no se puede abrir el archivo del objeto compartido: No existe el archivo o el directorio) libGL error: dlopen /usr/lib/dri/swrast_dri.so failed (/usr/lib/dri/swrast_dri.so: no se puede abrir el archivo del objeto compartido: No existe el archivo o el directorio) libGL error: unable to load driver: swrast_dri.so libGL error: failed to load driver: swrast Running Steam on ubuntu 14.04 64-bit

However the command strings /home/jose/.local/share/Steam/ubuntu12_32/steam-runtime/i386/usr/lib/i386-linux-gnu/libstdc++.so.6 | grep GLIB did show version 3.4.18.

Removing the libstdc++.so.6 libstdc++.so.6.0.16 files solved the issue and now steam starts with direct GPU acceleration.

[jsa1983]

By the way, the system's lib is 4.8.2-19ubuntu1 (libstdc++.so.6.0.19), using Ubuntu 14.04 as indicated in the log.

[jsa1983]

Sorry, my bad... the bundled library only provides the following versions, among which is not 3.4.18:

GLIBCXX_3.4 GLIBCXX_3.4.1 GLIBCXX_3.4.2 GLIBCXX_3.4.3 GLIBCXX_3.4.4 GLIBCXX_3.4.5 GLIBCXX_3.4.6 GLIBCXX_3.4.7 GLIBCXX_3.4.8 GLIBCXX_3.4.9 GLIBCXX_3.4.10 GLIBCXX_3.4.11 GLIBCXX_3.4.12 GLIBCXX_3.4.13 GLIBCXX_3.4.14 GLIBCXX_3.4.15 GLIBCXX_3.4.16

So it seems the bundled lib must be updated.

[jsa1983]

Now it's the same with libgcc_s.so.1 as stated in bug #3280

Running Steam on ubuntu 14.04 64-bit STEAM_RUNTIME is enabled automatically Installing breakpad exception handler for appid(steam)/version(1398287272_client) libGL error: dlopen /usr/lib/i386-linux-gnu/dri/radeonsi_dri.so failed (/home/jose/.local/share/Steam/ubuntu12_32/steam-runtime/i386/lib/i386-linux-gnu/libgcc_s.so.1: version GCC_4.7.0' not found (required by /usr/lib/i386-linux-gnu/dri/radeonsi_dri.so)) libGL error: dlopen ${ORIGIN}/dri/radeonsi_dri.so failed (${ORIGIN}/dri/radeonsi_dri.so: no se puede abrir el archivo del objeto compartido: No existe el archivo o el directorio) libGL error: dlopen /usr/lib/dri/radeonsi_dri.so failed (/usr/lib/dri/radeonsi_dri.so: no se puede abrir el archivo del objeto compartido: No existe el archivo o el directorio) libGL error: unable to load driver: radeonsi_dri.so libGL error: driver pointer missing libGL error: failed to load driver: radeonsi libGL error: dlopen /usr/lib/i386-linux-gnu/dri/swrast_dri.so failed (/home/jose/.local/share/Steam/ubuntu12_32/steam-runtime/i386/lib/i386-linux-gnu/libgcc_s.so.1: versionGCC_4.7.0' not found (required by /usr/lib/i386-linux-gnu/dri/swrast_dri.so))
libGL error: dlopen ${ORIGIN}/dri/swrast_dri.so failed (${ORIGIN}/dri/swrast_dri.so: no se puede abrir el archivo del objeto compartido: No existe el archivo o el directorio) libGL error: dlopen /usr/lib/dri/swrast_dri.so failed (/usr/lib/dri/swrast_dri.so: no se puede abrir el archivo del objeto compartido: No existe el archivo o el directorio) libGL error: unable to load driver: swrast_dri.so libGL error: failed to load driver: swrast Installing breakpad exception handler for appid(steam)/version(1398287272_client) Installing breakpad exception handler for appid(steam)/version(1398287272_client) Fontconfig error: "/etc/fonts/conf.d/10-scale-bitmap-fonts.conf", line 70: non-double matrix element Fontconfig error: "/etc/fonts/conf.d/10-scale-bitmap-fonts.conf", line 70: non-double matrix element Fontconfig warning: "/etc/fonts/conf.d/10-scale-bitmap-fonts.conf", line 78: saw unknown, expected number [0504/205725:WARNING:proxy_service.cc(958)] PAC support disabled because there is no system implementation libGL error: dlopen /usr/lib/i386-linux-gnu/dri/radeonsi_dri.so failed (/home/jose/.local/share/Steam/ubuntu12_32/steam-runtime/i386/lib/i386-linux-gnu/libgcc_s.so.1: version GCC_4.7.0' not found (required by /usr/lib/i386-linux-gnu/dri/radeonsi_dri.so)) libGL error: dlopen ${ORIGIN}/dri/radeonsi_dri.so failed (${ORIGIN}/dri/radeonsi_dri.so: no se puede abrir el archivo del objeto compartido: No existe el archivo o el directorio) libGL error: dlopen /usr/lib/dri/radeonsi_dri.so failed (/usr/lib/dri/radeonsi_dri.so: no se puede abrir el archivo del objeto compartido: No existe el archivo o el directorio) libGL error: unable to load driver: radeonsi_dri.so libGL error: driver pointer missing libGL error: failed to load driver: radeonsi libGL error: dlopen /usr/lib/i386-linux-gnu/dri/swrast_dri.so failed (/home/jose/.local/share/Steam/ubuntu12_32/steam-runtime/i386/lib/i386-linux-gnu/libgcc_s.so.1: versionGCC_4.7.0' not found (required by /usr/lib/i386-linux-gnu/dri/swrast_dri.so)) libGL error: dlopen ${ORIGIN}/dri/swrast_dri.so failed (${ORIGIN}/dri/swrast_dri.so: no se puede abrir el archivo del objeto compartido: No existe el archivo o el directorio) libGL error: dlopen /usr/lib/dri/swrast_dri.so failed (/usr/lib/dri/swrast_dri.so: no se puede abrir el archivo del objeto compartido: No existe el archivo o el directorio) libGL error: unable to load driver: swrast_dri.so libGL error: failed to load driver: swrast Error: OpenGL GLX context is not using direct rendering, which may cause performance problems.

For more information visit https://support.steampowered.com/kb_article.php?ref=9938-EYZB-7457.

[tomtomme]

deleting libgcc_s.so.1 of steam-runtime helped in my case #3291

[AsureDawn]

I couldn't get the console output because this issue was causing the xserver to crash for me. After mv libstdc++.so.6{,.bak} && mv libgcc_s.so.1{,.bak} everything works fine now. Well, there's this weird (infinitely repeating) bell sound when the "Connecting Steam Account" window is focused and the "Steam Guard" window is in the background...is it supposed to be modal? Probably a separate issue.

Almost forgot: on ArchLinux, (multilib-)testing and mesa-git enabled.

[scottlu]

Thanks for the bug report; we are aware of it and are working out the best way to fix it.

On Mon, May 26, 2014 at 2:08 PM, Benjamin Blanco notifications@github.comwrote:

I couldn't get the console output because this issue was causing the xserver to crash for me. After mv libstdc++.so.6{,.bak} && mv libgcc_s.so.1{,.bak} everything works fine now. Well, there's this weird (infinitely repeating) bell sound when the "Connecting Steam Account" window is focused and the "Steam Guard" window is in the background...is it supposed to be modal? Probably a separate issue.

— Reply to this email directly or view it on GitHubhttps://github.com/ValveSoftware/steam-runtime/issues/13#issuecomment-44218167 .

[sylware]

It's a bit of a mess, the library preloader must be able to figure the right libgcc and libstd++ from the same major version but with different dependencies!

[NotMrFlibble]

Putting these libraries in their own directory in the Steam runtime and using them only if needed (a simple test binary, linked against libGL, is probably enough to determine this), along with requiring that these are only distributed via Steam runtime (which will require a lot of game updates!), perhaps?

These are system libraries; it's just plain wrong for games to be distributing them.

[sylware]

On Thu, Jun 19, 2014 at 09:44:25AM -0700, NotMrFlibble wrote:

Putting these libraries in their own directory in the Steam runtime and using them only if needed (a simple test binary, linked against libGL, is probably enough to determine this), along with requiring that these are only distributed via Steam runtime (which will require a lot of game updates!), perhaps?

These are system libraries; it's just plain wrong for games to be distributing them.

Wrong. They are a lot of gnu/linux systems out there which decide what is "their" system (I don't have c++ on some systems for instance, which is a good thing since this language/runtime is more toxic and damaging than plain C, but this is not the topic here).

It should depend on a minimum set of system libs, the elf loader, and those linked to the hardware, like GL libs, pulseaudio/alsa libs. Valve is narrowing down those requirements even so they could not care at all, since they could base steam on the system libs from GNU/Linux debian7 (steamOS) and send all the others to Hell...

Is that what you want?

Sylvain

[scottlu]

Here are the things we are looking at right now...

• A new steam-runtime SDK release with support for gcc-4.8 and clang-3.4. This new SDK is contained in a chroot environment (used for the app's build environment, not when the app is run). This results in a stable, constant build environment independent of the host system version, ensures apps aren't pulling in dependencies from the underlying system, and makes it easy to customize and update.
• We're investigating making gcc-4.8's libstdc++ the default in the steam-runtime going forward. The investigation involves testing all current Linux games in the Steam library on Ubuntu 12.04 through 14.04 to see what compatibility issues may result. We are close to starting this test.
• We are also investigating a way to mark which steam-runtime version an app was built with, so that Steam can make runtime environment decisions when the app is launched, as necessary. This isn't very different from what other OS's do to know what runtime expectations an app has. For example if necessary Steam can ensure a given app has the libstdc++ and libgcc it expects.

Thanks, Scott

[NotMrFlibble]

I found that Witcher 2 with Mesa 10.2 built against llvm 3.4.1 and using radeonsi would fail with a register-related error; but building Mesa against an llvm 3.5 snapshot (Debian unstable) ends up with it requiring libc6 2.19 etc. However, so that the game runs fine, that's what I've done.

llibgl1-mesa-dri Depends: libc6 (>= 2.17), … , libgcc1 (>= 1:4.7), libllvm3.5, libstdc++6 (>= 4.6) llibllvm3.5 Depends: libc6 (>= 2.15), …, libgcc1 (>= 1:4.1.1), libstdc++6 (>= 4.8), …

So if the Steam runtime decides that a libstdc++ older than 4.8 can be used, it's going to break things here.

My understanding is that it's always safe to use newer libc6, libstdc++6 and libgcc1 (for libc.so.6, libstdc++.so.6 and libgcc_s.so.1, respectively) – and if not, it's a library bug.

[sylware]

On Sat, Jun 21, 2014 at 11:44:46AM -0700, Scott Ludwig wrote:

• We're investigating making gcc-4.8's libstdc++ the default in the steam-runtime going forward. The investigation involves testing all current Linux games in the Steam library on Ubuntu 12.04 through 14.04 to see what compatibility issues may result. We are close to starting this test.

The runtime should rely only on the ELF loader. Everything else should be bundled except the libs which contains system/hardware specific "ultra stable over time" interfaces like GL and alsa. The runtime should be able to "cherry pick" all its dependencies. That would help making the steam-runtime run on most GNU/Linux distros. Additionnaly, carefull of compilers and their run-times: Do not assume you have specific compilers with their run-times on all distros with the "right" version... with clang/gcc/tinycc/open64/glibc/musl/eglibc/dietlibc... bundle those you use in the steam run-time... only rely on the ELF loader, and the really necessary system libs (compilers runtimes should not be part of this really necessary system set of libs). That should make the steam runtime work on nearly all GNU/Linux distros and be able to troubleshoot in a fine way all system dependency issues.

Oh! I forgot... plz! 64 bits native builds! ;). Namely steam should be able to differenciate 32bits/64bits like the OS (windows/marcOS/linux(steamOS)) for games. Hardware manufacturers seem to go multi-arch support. For instance (see AMD), power hungry speed cores using x86_64 and power efficient but quite slower ARM cores may exist in the not too distant futur.

best regards,

Sylvain

[sylware]

I stand corrected by myself: It may be a very good idea to bundle the ELF loader in the steam runtime and rely only on the library paths in /etc/ld.so.conf and /etc/ld.so.conf.d/ in order to locate x11/GL(wayland?) and alsalib. ELF is supposed to be a strict and stable binary interface, even better than GL and alsalib.

[stuartpb]

As you can see by the issues raised above, bundling core libraries like libstdc++ causes hella conflicts with environmentally-supplied libraries like video drivers, as seen on Arch Linux: https://wiki.archlinux.org/index.php/Steam#Steam_Runtime_issues

[sylware]

Well, nothing new: c++ is a hell of a pain. c++ is a good tutorial language to learn object oriented programming, but in no way it should be used "in real life". My 2 c.

The real issue is the dynamic linking of proper libstdc++, namely c++ symbols linking. In one same process, the steam runtime should use its libstdc++, and the "environmental" libs their libstdc++ in that same process: the steam runtime deals with the environmental libs with a C API then no need to share a common c++ runtime infrastructure. Maybe a trick is possible with symbol versioning at linking time. As another matter, be warned now of the c++ gcc ABI: it is well known to be one of the worse hell on earth. I let you think about clang and gcc ABI compatibility. Knowing the insanity of c++ ABIs I would not risk myself into such risks for binary only packages. Steam is at the application level, the real bad guys in the story are those coders of the environmentally supplied libs, they should not have used c++ in their runtim dependencies.

The real answer: since steam does work with the system libs only with C APIs (that's what will save them), it's ok to statically link their libstdc++ into their binaries.

(We could also discuss of the stability of the libgcc C API...)

[scottlu]

Original author of this bug, please try your scenario again, I believe it's fixed. If it isn't fixed, please reopen this bug. The steam runtime in the current public steam client has been updated with gcc 4.8's libgcc and libstdc++.

Also note a new steam runtime SDK release has been made with support for gcc 4.8 and clang 3.4.

[NotMrFlibble]

I temporarily restored the Steam-supplied libstdc++.so.6 and libgcc_s.so.1, restarted Steam, and promptly got the “not using direct rendering” dbox. You're supplying libraries from GCC 4.8, and I'm currently using OpenGL libs packaged for Debian jessie (mainly because that way I get decent open radeonsi support), and these require libstdc++ & libgcc_s from GCC 4.9 (which is the default version for Debian jessie).

At present, even if you move to GCC 4.9, I expect the same situation to happen soon after GCC 5 is out…

[sylware]

@NotMrFlibble is right: this is a short term fix. I do follow very closely radeon open driver development (I have my radeonsi driver) and you need the lastest and greatest of linux and mesa because dev is going fast and a lot is happening all the time. Even with debian sid you will lag A LOT: you need git linux and mesa libs.... And mesa uses a glsl compiler written in c++ with llvm: it's A HUGE UGLY KLUDGE (like linux drm), then get ready for hell if you want to enjoy the best of the open radeonsi driver. If khronos does its job properly, opengl NG should save us all (I don't trust the guys from khronos, I'm sure they will put a brain damage video memory abstraction layer that will make writting a driver another hell...).

Back to c++ mess.

We are dealing with the c++ ABIs and linking hell.

The only long term way is to have the steam runtime dynamically load its libstdc++ with a dynamic link trick (maybe symbol versionning), or statically link libstdc++.

BTW, you should do the same with libgcc...

[pinumbernumber]

This problem occurs on Ubuntu 14.10 now too.

(For anyone like me who was searching for a quick fix):

mv ~/.local/share/Steam/ubuntu12_32/steam-runtime/i386/lib/i386-linux-gnu/libgcc_s.so.1{,.disable}
mv ~/.local/share/Steam/ubuntu12_32/steam-runtime/i386/usr/lib/i386-linux-gnu/libstdc++.so.6{,.disable}

Renaming those libraries will force the use of system-wide ones. Which might possibly cause ABI issues, but will at least allow things to start normally and use DRI.

[stuartpb]

@scottlu Please reopen this issue - the problem still occurs, for the reasons explained above (the files don't match on any system where the rest of the system uses another GCC, which includes Debian and will likely soon include Ubuntu). This is, and will continue to be, an issue as long as Steam ships with these libraries as part of the runtime.

This issue can only be closed once i386/lib/i386-linux-gnu/libgcc_s.so.1 and i386/usr/lib/i386-linux-gnu/libstdc++.so.6 are removed from the list of files included in ~/.local/share/Steam/ubuntu12_32/steam-runtime. I don't know a single distro out there that doesn't ship with its own copy of these, so I can't see removing them causing any problems (while I can see it fixing numerous problems).

[sylware]

Yep. I don't you can cherry pick a specific version of the libstdc++ and libgcc* with libdl*. gcc has the static options to compile those libs as static (from gcc 4.7.x I think). It seems to be the only way to avoid collision with the dependencies from the system libs (GL, x11...).

[terzag]

Looks like a recent update of Steam runtime broke it again on Ubuntu 14.10 ("libGL error: unable to load driver: swrast_dri.so" / "OpenGL GLX context is not using direct rendering, which may cause performance problems."). Even removing the libs as in pinumbernumer's message, or the ones from the Arch wiki doesn't solve the problem. It happens only when using Catalyst (either the version from the Ubuntu repos or the new 14.12 released yesterday), Mesa works fine.

Any idea what to do to have a working Steam on Ubuntu 14.10 using Catalyst?

[sylware]

On Wed, Dec 10, 2014 at 04:35:39AM -0800, terzag wrote:

Any idea what to do to have a working Steam on Ubuntu 14.10 using Catalyst?

AMD is officially dropping catalyst on linux. Only the open source (and rightfully legal) driver will be supported on linux.

The core of the pb is gcc and c++ kludgyness, not the GL driver. You are targetting the wrong culprit. conclusion: don't use c++, stick to C, C90, even if it's a bit more rough around the edges. Valve can fix those by compiling their programs with static-libgcc and static-libstdc++.

My 2c.

Sylvain

[terzag]

Well, AFAIK, they're not dropping Catalyst, they plan to merge Catalyst and the free driver. Either way, it won't happen soon and the free driver itself has some really problematic issues with some games.

Besides, Steam worked fine with Catalyst before the nov. 22 update of Steam Runtime, so it looks like the problem comes from it (or from my system?) and may be fixed by removing some other libs from the runtime?

[sylware]

On Wed, Dec 10, 2014 at 06:20:26AM -0800, terzag wrote:

Well, AFAIK, they're not dropping Catalyst, they plan to merge Catalyst and the free driver. Either way, it won't happen soon and the free driver itself has some really problematic issues with some games.

Nothing new will happen in catalyst on linux based operating systems. They will let it die. Everything new on linux happens in the open source driver (which actually is the winCE driver base). Watch FOSDEM video from Alex. Deucher (nick agd5f), AMD.

On Wed, Dec 10, 2014 at 06:20:26AM -0800, terzag wrote:

Besides, Steam worked fine with Catalyst before the nov. 22 update of Steam Runtime, so it looks like the problem comes from it (or from my system?) and may be fixed by removing some other libs from the runtime?

Yes, get rid of libstdc++ and libgcc from the 32bits and 64bits steam runtimes. That workaround is written down in many github issues.

To "quick" fix this, valve must use the static-libgcc and static-libstdc++ compilation options from gcc and stop distributing those libs. BTW, nobody should use gcc 4.7.x or above since, from its 4.8 version, gcc is to be avoided like hell for the reason right below. The culprit is c++ kludgyness. Do NOT use c++. Use C90, even if it's a bit more rough on the edge.

Sylvain

[terzag]

Well that's my point: while it used to work previously, getting rid of libgcc and libstdc++ from Steam Runtime doesn't seem to be enough with the latest update.

I removed the following (according to the Arch wiki, I think): rm ~/.local/share/Steam/ubuntu12_32/steam-runtime/i386/usr/lib/i386-linux-gnu/libstdc++.so.6 rm ~/.local/share/Steam/ubuntu12_32/steam-runtime/i386/lib/i386-linux-gnu/libgcc_s.so.1 rm ~/.local/share/Steam/ubuntu12_32/steam-runtime/amd64/lib/x86_64-linux-gnu/libgcc_s.so.1 rm ~/.local/share/Steam/ubuntu12_32/steam-runtime/amd64/usr/lib/x86_64-linux-gnu/libstdc++.so.6 rm ~/.local/share/Steam/ubuntu12_32/steam-runtime/i386/usr/lib/i386-linux-gnu/libxcb.so.1

Are there other libs that need to be removed?

[sylware]

On Wed, Dec 10, 2014 at 08:23:35AM -0800, terzag wrote:

Well that's my point: while it used to work previously, getting rid of libgcc and libstdc++ from Steam Runtime doesn't seem to be enough with the latest update.

Those libs are "re-installed" after some steam updates...

I removed the following (according to the Arch wiki, I think): rm ~/.local/share/Steam/ubuntu12_32/steam-runtime/i386/usr/lib/i386-linux-gnu/libstdc++.so.6 rm ~/.local/share/Steam/ubuntu12_32/steam-runtime/i386/lib/i386-linux-gnu/libgcc_s.so.1 rm ~/.local/share/Steam/ubuntu12_32/steam-runtime/amd64/lib/x86_64-linux-gnu/libgcc_s.so.1 rm ~/.local/share/Steam/ubuntu12_32/steam-runtime/amd64/usr/lib/x86_64-linux-gnu/libstdc++.so.6 rm ~/.local/share/Steam/ubuntu12_32/steam-runtime/i386/usr/lib/i386-linux-gnu/libxcb.so.1

Are there other libs that need to be removed?

Before testing anything else, be sure to have tested the steam beta client on your gnu/linux distribution.

I don't recall libxcb needed to be removed from recent steam runtime, but for the other libs, yes, those libs are those I do remove to make it work on an up-to-date x86_64 fedora rawhide gnu/linux.

Sylvain

[terzag]

I made Steam redownload the runtime today and removed the libs after that. With or without them, I have the same problem. I can confirm that they're currently deleted and Steam gives me the GLX context error message. Will try the beta.

EDIT: same problem with the beta.

EDIT: mmm... I suspect the problem is on my config as I've just discovered that I have issues with WebGL too. Glxinfo says that I have direct rendering, though.

[sylware]

On Wed, Dec 10, 2014 at 08:56:22AM -0800, terzag wrote:

I made Steam redownload the runtime today and removed the libs after that. With or without them, I have the same problem. I can confirm that they're currently deleted and Steam gives me the GLX context error message. Will try the beta.

Start the steam client from a terminal. It gives you a lot of info which can help pinpoint the issue.

Sylvain

[terzag]

Oh, I opened a thread on the Steam forums but I forgot to add the infos here:

Running Steam on ubuntu 14.10 64-bit STEAM_RUNTIME is enabled automatically Installing breakpad exception handler for appid(steam)/version(1416617579) libGL error: No matching fbConfigs or visuals found libGL error: failed to load driver: swrast Installing breakpad exception handler for appid(steam)/version(1416617579) Installing breakpad exception handler for appid(steamwebhelper)/version(20141121162341) Installing breakpad exception handler for appid(steamwebhelper)/version(1416587021) Installing breakpad exception handler for appid(steamwebhelper)/version(20141121162341) Installing breakpad exception handler for appid(steamwebhelper)/version(1416587021) Installing breakpad exception handler for appid(steamwebhelper)/version(1416587021) [1210/134308:ERROR:nss_util.cc(1018)] Failed to load NSS libraries. Installing breakpad exception handler for appid(steam)/version(1416617579) Fontconfig error: "/etc/fonts/conf.d/10-scale-bitmap-fonts.conf", line 70: non-double matrix element Fontconfig error: "/etc/fonts/conf.d/10-scale-bitmap-fonts.conf", line 70: non-double matrix element Fontconfig warning: "/etc/fonts/conf.d/10-scale-bitmap-fonts.conf", line 78: saw unknown, expected number libGL error: No matching fbConfigs or visuals found libGL error: failed to load driver: swrast Error: OpenGL GLX context is not using direct rendering, which may cause performance problems [...]

If I stay with the original Steam Runtime, I get basically the same output but with the following libGL errors:

libGL error: unable to load driver: swrast_dri.so libGL error: failed to load driver: swrast

To check if the problem is specific to my system, I tried Darkplaces (Quake) and it works fine, except that when trying the 32-bit version, it displays no textures/garbage graphics (64 bit version is ok). But apart from that, it runs at full speed, no GL error or software render or something like that.

[sylware]

On Wed, Dec 10, 2014 at 10:59:05AM -0800, terzag wrote:

libGL error: failed to load driver: swrast libGL error: No matching fbConfigs or visuals found libGL error: failed to load driver: swrast libGL error: failed to load driver: swrast[/code]

To check if the problem is specific to my system, I tried Darkplaces (Quake) and it works fine, except that when trying the 32-bit version, it displays no textures/garbage graphics (64 bit version is ok). But apart from that, it runs at full speed, no GL error or software render or something like that.

Ok... it means you have a pb with your gnu/linux distribution, not with steam. OpenGL with hardware acceleration does not work on your gnu/linux distribution.

Get in contact with the http://www.mesa3d.org/ guys. They will help you figure out why your opengl setup is screwed.

Sylvain

[AsureDawn]

Make sure 32-bit gl/DRM libs are installed. Packages could be called ia32 or lib32-, in the main or multilib repo, depending on your distro.

Also, try running the game from a terminal/console directly instead of through steam. Sometimes (for me) the game refuses to run through steam (with graphic library errors), but runs fine if ran directly. Steam still needs to be running, of course.

[dequis]

Can this be reopened? Still had to remove libstdc++.so after the last update.

[mikefaille]

I used Steam regularly with Fedora 19/20/21 and I never saw this issue. Maybe, it's only a Ubuntu/(Debian ?) case. Oh, and, I'm a Steam beta tester.

[dequis]

The arch linux wiki (permalink) suggests it's something specific to the radeon open source driver.

[sylware]

On Tue, Jan 20, 2015 at 08:46:37AM -0800, dx wrote:

The arch linux wiki suggests it's something specific to the radeon open source driver.

libgcc and libstdc++ are a mess (the usual c++ ABI kludge and gcc being "more than a machine code generator").

Valve and games should statically link libgcc and libstdc++ into their runtime to avoid many conflicts and more. For instance libstdc++ provides GCC c++ ABI, which is GCC only, then coupling games and steam runtime with gcc only and that forever. Asking another c++ compiler to follow GCC c++ ABI is asking for troubles, it's insane, period. The only reasonable binary interface is ELF with basic C symbols (even the versioned symbols may bring to you a nice set of troubles).

... or ALL gnu/linux distros should statically link libgcc and libstdc++ in their graphic and sound stack:x11 libs, 3D libs, alsalib (pulseaudio interface is not reasonnable, better stick with alsa and let pulseaudio do audio software mixing as an alsalib module).

Sylvain

[dequis]

@sylware just curious, do you work at valve?

[mikefaille]

I don't think main gnu/linux distro will statically link libgcc and libstdc++; dynamics libs help so much for small/frequent/important updates.

[weirddan455]

@sylware The problem is even IF Valve were to statically link libsdtc++ they still have third-party games to support. There's no way to get ALL the third-party devlopers to recompile their already released games just for this. Also, nearly all Linux distributions frown on statically linking their system libraries. That's not the answer either.

IMO the best solution is to simply remove libstdc++ from steam-runtime and let it use the system library there. libstdc++ is designed to be forward-compatible. I quote: https://gcc.gnu.org/onlinedocs/libstdc++/manual/abi.html

Extending existing, stable ABIs. Versioning gives subsequent releases of library binaries the ability to add new symbols and add functionality, all the while retaining compatibility with the previous releases in the series. Thus, program binaries linked with the initial release of a library binary will still run correctly if the library binary is replaced by carefully-managed subsequent library binaries. This is called forward compatibility.

The reverse (backwards compatibility) is not true. It is not possible to take program binaries linked with the latest version of a library binary in a release series (with additional symbols added), substitute in the initial release of the library binary, and remain link compatible.

Therefore the only problem should be with systems that have a libstdc++ that's too outdated so perhaps Valve could write a script that places that library in steam-runtime only if the system version is too old.

I personally haven't had any problems using my system's libstdc++ and I'm on Arch Linux with gcc-libs 4.9.2 which you claim to be terrible (works just fine for me and I've not read reports from other Arch users about breakage there.)

[sylware]

On Wed, Jan 21, 2015 at 03:32:39AM -0800, weirddan455 wrote:

@sylware The problem is even IF Valve were to statically link libsdtc++ they still have third-party games to support. There's no way to get ALL the third-party devlopers to recompile their already released games just for this. Also, nearly all Linux distributions frown on statically linking their system libraries. That's not the answer either.

IMO the best solution is to simply remove libstdc++ from steam-runtime and let it use the system library there. libstdc++ is designed to be forward-compatible. I quote: https://gcc.gnu.org/onlinedocs/libstdc++/manual/abi.html

"Extending existing, stable ABIs. Versioning gives subsequent releases of library binaries the ability to add new symbols and add functionality, all the while retaining compatibility with the previous releases in the series. Thus, program binaries linked with the initial release of a library binary will still run correctly if the library binary is replaced by carefully-managed subsequent library binaries. This is called forward compatibility.

The reverse (backwards compatibility) is not true. It is not possible to take program binaries linked with the latest version of a library binary in a release series (with additional symbols added), substitute in the initial release of the library binary, and remain link compatible. "

Therefore the only problem should be with systems that have a libstdc++ that's too outdated so perhaps Valve could write a script that places that library in steam-runtime only if the system version is too old.

I personally haven't had any problems using my system's libstdc++ and I'm on Arch Linux with gcc-libs 4.9.2 which you claim to be terrible (works just fine for me and I've not read reports from other Arch users about breakage there.)

There is a difference between theory and reality. The theory will always be beautifull, but the reality=tons a troubles (usually proportional of the complexity of the components and the time frame of support).

There are 2 pbs: the c++ ABI kludge/mess (any c++ compiler), and the gcc specific libgcc mess. Removing libstdc++ would mean that the runtime is hard dependent an gcc c++ ABI, same thing for libgcc. Ground experience and common sense dictates that the most important target for a binary runtime is to depend on as few as possible interfaces which should be as simple as possible to maximize its chances to run on "any distro".

For the game "industry", that minimal set of distro interfaces would be:

• ELF loader with a minimal linux syscalls abstraction layer (usually a subset of libc "standard")
• ELF x11/GL libs (display/3D and keyboard/mouse)
• ELF libalsa (sound, actually I don't know if it can handle dynamic plug/unplug of microphone properly though).
• linux device nodes for pad/joystick, usually /dev/input/jsX. (Do not rely on ELF libudev, as this component does exist in many "flavors" now which, on paper, do work together, and in reality not really, use direct uevent netlink/sysfs linux interface avoiding to use any information enrichment provided by a system udev)

Everything "above" should be packaged and shipped with the binary runtime. That means statically linked to avoid symbol conflicts with the ELF dependency graph of those libs (or manually load ELF libs with manual symbol resolving). For instance Mesa (most of GL libs out there), pulls libstdc++ because of llvm. I'm currently testing steam with a fedora rawhide gcc 4.9.2, steam runtime libgcc and libstdc++ do not work and do conflict. I'll soon use a custom minimal distro based on above interfaces. The proper course of action with such a mess, is to avoid conflicts with static linking or manual ELF loading: gcc interfaces (c++ ABI and libgcc) are a kludgy/brain damaged mess, do not rely on their "theorical" stability. Even ELF with symbol versionning is troublesome...

my 2 c,

Sylvain

[sylware]

On Tue, Jan 20, 2015 at 11:52:35AM -0800, dx wrote:

@sylware just curious, do you work at valve?

Nope. I'm unemployed and closing to homelessness. Then no conflict of interest here. Only the will to make things work with the minimal global technical cost.

Sylvain

[sylware]

On Tue, Jan 20, 2015 at 12:17:00PM -0800, mikefaille wrote:

I don't think main gnu/linux distro will statically link libgcc and libstdc++.

Wrong, I say ALL linux distros... ;) (irony)

Sylvain

[chrisjamesberg]

Still having this problem running Trusty on second Gen chromebook pixel. Deleting all these files doesn't solve my problem.

[chrisjamesberg]

This is the error I'm getting after deleting all those files. ERROR: ld.so: object '/home/chrisberg/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored.

[devurandom]

@chrisjamesberg I would say that your problem is that Steams is trying to load a 32-bit library (gameoverlayrenderer.so) into a 64-bit program.

[mdiluz]

@chrisjamesberg @devurandom that message is seen in all steam games as steam puts both the 32bit and 64bit overlay in LD_PRELOAD, one will always fail. I wouldn't consider it an error, it's an unfortunate side effect.

[at46]

You can use _LDPRELOAD='/usr/$LIB/libstdc++.so.6' steam to start steam as a workaround for this problem. It allows you to start steam with the system version of the lib without deleting the integrated one. Works great for me. Source: https://wirejungle.wordpress.com/2015/01/09/how-to-fix-broken-steam-linux-client-with-radeon-graphics-driver-workaround/

[sharkwouter]

Why has this issue been closed? I've encountered this on Debian Jessie, Arch Linux, Ubuntu 14.10+, OpenSUSE 13.2, Fedora 21 and SteamOS Brewmaster.

[sylware]

On Sat, Jun 27, 2015 at 03:50:09PM -0700, Wouter Wijsman wrote:

Why has this issue been closed? I've encountered this on Debian Jessie, Arch Linux, Ubuntu 14.10+, OpenSUSE 13.2, Fedora 21 and SteamOS Brewmaster.

The steamruntime provided to game devs should provide a static libstdc++ and a static libgcc.

c++ ABI and libgcc are troubles, always.

[RobLoach]

Just ran into this again, and @pinumbernumber's fix at https://github.com/ValveSoftware/steam-runtime/issues/13#issuecomment-60326157 fixed it.