Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
jsa1983 opened this issue Apr 26, 2014 · 89 comments
Closed

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

jsa1983 opened this issue Apr 26, 2014 · 89 comments

Comments

@jsa1983
Copy link

jsa1983 commented Apr 26, 2014

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
Copy link
Author

jsa1983 commented Apr 26, 2014

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 jsa1983 closed this as completed Apr 26, 2014
@jsa1983 jsa1983 reopened this Apr 26, 2014
@jsa1983
Copy link
Author

jsa1983 commented Apr 26, 2014

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
Copy link
Author

jsa1983 commented May 4, 2014

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
Copy link

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

@AsureDawn
Copy link

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
Copy link

scottlu commented May 27, 2014

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//issues/13#issuecomment-44218167
.

@sylware
Copy link

sylware commented May 30, 2014

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
Copy link

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
Copy link

sylware commented Jun 19, 2014

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
Copy link

scottlu commented Jun 21, 2014

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
Copy link

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
Copy link

sylware commented Jun 22, 2014

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
Copy link

sylware commented Jun 23, 2014

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
Copy link

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
Copy link

sylware commented Sep 23, 2014

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
Copy link

scottlu commented Sep 24, 2014

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.

@scottlu scottlu closed this as completed Sep 24, 2014
@NotMrFlibble
Copy link

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
Copy link

sylware commented Sep 24, 2014

@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
Copy link

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.

@sylware
Copy link

sylware commented Nov 4, 2015

On Wed, Nov 04, 2015 at 03:01:34AM -0800, Mark K Cowan wrote:

@sylware:

This is not a bug

I beg to differ:

Games working before LD_PRELOAD hack: 0
Games working after LD_PRELOAD hack: at least 5, none broken so far

'broken by design' is way worse than a bug.

@battlesnake
Copy link

'broken by design' is way worse than a bug.

@sylware: That goes for the steam client too.

@sylware
Copy link

sylware commented Nov 4, 2015

On Wed, Nov 04, 2015 at 03:52:28AM -0800, Mark K Cowan wrote:

'broken by design' is way worse than a bug.

@sylware: That goes for the steam client too.

Well, as I said, the real culprits are the "open source" guys who have the
proper resources to work on gcc. My guess they are corporate salary men and
they try to perform developer lock-in by open source complexity.

@battlesnake
Copy link

My guess they are corporate salary men and they try to perform developer lock-in by open source complexity.

Jet fuel can't melt steel beams! :trollface:

@mmstick
Copy link

mmstick commented Nov 9, 2015

@sylware There's nothing wrong with the 'open source guys' because this issue has been discussed plenty of times about how easy it is to solve this if Valve would do it. Valve needs to stop trying to override system libraries, especially libstdc++ and libgcc, because this breaks Mesa and DRI unless they are built statically. VMWare solved this exact problem just by putting each library into its own directory and only adding the necessary directories to $LD_LIBRARY_PATH.

The other option is telling everyone to go back and recompile their games with those two libraries being compiled statically into the game itself. I don't even see why Valve is shipping these two libraries in their runtime anyway because that in itself is a terrible idea unless you are are wanting to issue security updates to your C++ runtimes regularly, which Valve doesn't seem to be doing at all with their frozen runtimes, which defeats the purpose entirely.

http://patchwork.freedesktop.org/patch/44437/

@sylware
Copy link

sylware commented Nov 10, 2015

I was talking about the "open source" guys from gcc, not all of them. I'm one
of the other open source guys, and as one of them, I would try never to
become hard dependent on gcc, ever ever ever ever (Their c++ move killed them
in my heart).

Common sense and sanity dictate binary software needs minimal simple stable
system ABI over time (i.e. no c++ toolchain dependent ABI) and everything
"above" this ABI should be "packaged" into the binaries to avoid, as much as
possible, bad interferences with the system. Share libs are a fail to "package"
nasty libs like ultra complex ABI and toolchain dependent libstdc++ and
toolchain dependent libgcc with 0 interference. Then in the SDK, just make them
static and we are done... till the next interference.

The minimal simple ABI for games should be something like that:

  • sound: SDL2->libpulse (ouch... since pulse ABI is a moving target) and
    libasound (way more ABI stable but missing out of the box software mixer)
    shared libs.
  • GFX/3D: SDL2 on vulkan/(egl/glx/wayland?)opengl/d3d libs (opengl'S' are a
    bloody ABI mess... lot of hope in vulkan...)
  • application system ABI(ELF): "libdl" to load the previous system libs with
    their system dependencies in game processes.

Everything else should be static. Even SDL2, and I would even consider the ELF
loader as static, to sort of "freeze" ELF.

@mmstick
Copy link

mmstick commented Apr 2, 2016

Can we please at least have the steam.desktop application patched so that it says

Exec=env LD_PRELOAD='/usr/$LIB/libstdc++.so.6 /usr/$LIB/libgcc_s.so.1 /usr/$LIB/libxcb.so.1' /usr/bin/steam %U

Instead of

Exec=/usr/bin/steam %U

Even better is to just have a very simple, very convenient few lines of code in the Steam launch script to execute this one little LD_PRELOAD line when open source drivers are detected. This is still a serious problem in 2016.

@sylware
Copy link

sylware commented Apr 3, 2016

On Sat, Apr 02, 2016 at 10:53:47AM -0700, Michael Murphy wrote:

Can we please at least have the steam.desktop application patched so that it says

Exec=env LD_PRELOAD='/usr/$LIB/libstdc++.so.6 /usr/$LIB/libgcc_s.so.1 /usr/$LIB/libxcb.so.1' /usr/bin/steam %U

It's deeper than that. You will have troubles with X libs pulling c++ stuff
from mesa (last time I checked, namely a long time ago).

The real issue is c++ and libgcc in themself: the c++ ABI is just compiler
specific (and an insane nightmare) and libgcc_s is weird.

Steam SDK should contain static libstdc++ and static libgcc in order to
minimize the side-effects with the various gnu/linux based OSes out there.
(that seems the real fix to this issue).

Don't forget that interop moto is to keep interfaces hardcore simple, thus
basic ELF ABI.

Sylvain

@jurf
Copy link

jurf commented May 14, 2016

But can you override LD_PRELOAD as @mmstick said if the user force disables the runtime with STEAM_RUNTIME=0? I think it would be the best solution/work-around right now and would stop users having to apply all these crazy hacks.

@mmstick
Copy link

mmstick commented May 14, 2016

Recent changes to the Steam runtime now requires a new LD_PRELOAD hack, due to an issue with libgpg-error.

env LD_PRELOAD='/usr/$LIB/libstdc++.so.6 /usr/$LIB/libgcc_s.so.1 /usr/$LIB/libxcb.so.1 /usr/$LIB/libgpg-error.so' /usr/bin/steam %U

@mmstick
Copy link

mmstick commented May 14, 2016

@DoctorJellyface The fix would actually be much easier than this. Just apply a few lines of shell to the steam.sh script and you're good to go. The fix could be as simple as the following (and this does actually work):

if [ "$(glxinfo | grep Mesa)" ]; then
    LD_PRELOAD='/usr/$LIB/libstdc++.so.6 /usr/$LIB/libgcc_s.so.1 /usr/$LIB/libxcb.so.1 /usr/$LIB/libgpg-error.so' exec "$LAUNCHSTEAMDIR/$STEAMBOOTSTRAP" "$@"
else
    exec "$LAUNCHSTEAMDIR/$STEAMBOOTSTRAP" "$@"
fi

@tfhavingfun
Copy link

@mmstick You just provided Valve with the easiest fix. So thanks. Let's hope they listen.

@evhfiftyone50
Copy link

@tfhavingfun Could you please elaborate where you put the code into steam.sh? The way I have tried it still resulted in the same error. But then again I am quite new to this and probably messed something up.
Thanks!

@pavlos256
Copy link

@evhfiftyone50 What I did was create a tiny shell script and start steam with it:

#!/bin/bash
env LD_PRELOAD='/usr/$LIB/libstdc++.so.6 /usr/$LIB/libgcc_s.so.1 /usr/$LIB/libxcb.so.1 /usr/$LIB/libgpg-error.so' /usr/bin/steam %U

@tfhavingfun
Copy link

tfhavingfun commented Sep 17, 2016

@evhfiftyone50 I don't recommend editing steam.sh directly. Instead just create a shell script as suggested by @pavlos256 and use a custom desktop file for Steam within which you can then refer to the shell script. That way you can just click the Steam icon (be it on your Desktop or Dash/Dock) to start it as you would normally do. Here is a video I made demonstrating how to do that: https://www.youtube.com/watch?v=gdM1S39mjgY

@HarlemSquirrel
Copy link

I made a desktop file I made by copying the original desktop file and modifying Name and EXEC to use the line from @pavlos256

cp /usr/share/applications/steam.desktop ~/.local/share/applications/steam-preload-libs.desktop.desktop
Name=Steam (preload libs)
Exec=env LD_PRELOAD='/usr/$LIB/libstdc++.so.6 /usr/$LIB/libgcc_s.so.1 /usr/$LIB/libxcb.so.1 /usr/$LIB/libgpg-error.so' /usr/bin/steam %U

I also made it executable and refreshed my GNOME desktop so I could find it and click on it.

chmod +x /home/hs/.local/share/applications/steam-preload-libs.desktop.desktop

@zygimantus
Copy link

zygimantus commented Nov 2, 2016

In ArchLinux the solution for me was: rm ~/.local/share/Steam/ubuntu12_32/steam-runtime/i386/usr/lib/i386-linux-gnu/lib*

@Swyter
Copy link

Swyter commented Nov 2, 2016

Arch Linux now has a steam-native-runtime meta-package in the Community/Multilib repository with all the needed Steam dependencies. So this shouldn't be a problem any longer.

https://wiki.archlinux.org/index.php/Steam/Troubleshooting#Native_runtime

Just install that and launch steam-native instead of steam.

Boom! You are done, no more deletions.

@sylware
Copy link

sylware commented Nov 3, 2016

Just updated my custom gnu/linux distro.

32 bits libs are a massive pain to build/setup, since you must use a multi-lib gcc.
It's not reasonable to try to split cleanly 32 bits and 64 bits infrastructures.

I do really think, it's time to provide a clean 64 bits client on gnu/linux.
(big picture?)

I can try to help (I'm humble), even though I'm an open source fan and c++
hater (for very good reasons). I'm currently available.

@ghost
Copy link

ghost commented Nov 11, 2016

pacman -S steam-native-runtime

(just run it...)

@LotosikRa
Copy link

@Swyter How to install this kind of package?

@mikefaille
Copy link

mikefaille commented Dec 30, 2016

@LotosikRa In which Linux Distro ?

@LotosikRa
Copy link

@mikefaille Ubuntu 16.10

@mikefaille
Copy link

mikefaille commented Dec 30, 2016

@LotosikRa You don't need this on Ubuntu. You already have "steam native" libs where native platform = Ubuntu/Debian. Just install steam from "Ubuntu Software".

@LotosikRa
Copy link

@mikefaille Did You mean that Ubuntu's steam package have all what I need? What does

Just install steam apt://steam

mean?

@mikefaille
Copy link

mikefaille commented Dec 30, 2016

@LotosikRa
My bad, just check my edited post. #13 (comment)

@mmstick
Copy link

mmstick commented Dec 30, 2016

You'll still have the same problem with the steam runtime because Ubuntu is not actually an officially supported platform, even though it is claimed to be officially supported. You will need to apply the same fixes as other distributions to get working drivers in Steam games for Ubuntu 16.10. The same solution for Arch Linux applies to Ubuntu -- deleting the conflicting libs. I'm not aware of any PPAs providing a native runtime for Ubuntu.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests