Bug 78242 - Steam cannot load mesa drivers (libGL error: driver pointer missing)
Summary: Steam cannot load mesa drivers (libGL error: driver pointer missing)
Status: RESOLVED NOTOURBUG
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/Gallium/r600 (show other bugs)
Version: git
Hardware: Other All
: medium normal
Assignee: Default DRI bug account
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-05-04 06:21 UTC by Kertesz Laszlo
Modified: 2014-05-17 15:46 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Kertesz Laszlo 2014-05-04 06:21:22 UTC
I rebuilt mesa recently (on Debian Testing 64 bit) an i see that Steam is broken again. I get this in a terminal (accompanied by a graphical popup saying "OpenGL GLX context is not using direct rendering, which may cause performance problems.") :

Running Steam on debian  64-bit
STEAM_RUNTIME is enabled automatically
Installing breakpad exception handler for appid(steam)/version(1398120891_client)
libGL error: dlopen /usr/lib/i386-linux-gnu/dri/r600_dri.so failed (/media/bigdata/games/.steam/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/r600_dri.so))
libGL error: unable to load driver: r600_dri.so
libGL error: driver pointer missing
libGL error: failed to load driver: r600
libGL error: dlopen /usr/lib/i386-linux-gnu/dri/swrast_dri.so failed (/media/bigdata/games/.steam/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/swrast_dri.so))
libGL error: unable to load driver: swrast_dri.so
libGL error: failed to load driver: swrast

Then other Steam specific stuff.
The Steam GUI launches but cannot launch anything.

Now i dont know what is the issue here since i built Mesa this way since a very long time ago, with my current (gcc 4.8) compiler and had no such issues.

strings /media/bigdata/games/.steam/steam/ubuntu12_32/steam-runtime/i386/lib/i386-linux-gnu/libgcc_s.so.1 | grep GCC_4
GCC_4.0.0
GCC_4.2.0
GCC_4.3.0
GCC_4.4.0
GCC_4.5.0

Other 64 and 32 bit opengl games seems to work fine.
Comment 1 Laurent carlier 2014-05-04 08:44:25 UTC
rm /media/bigdata/games/.steam/steam/ubuntu12_32/steam-runtime/i386/lib/i386-linux-gnu/libgcc_s.so.1

should fix the problem. It's a steam bug, not a mesa one
Comment 2 Sylvain BERTRAND 2014-05-07 21:00:39 UTC
Lastest update of fedora rawhide triggered this bug.

If I understood well, the steam preloaded libs use a different libgcc than the system dependent libs.

Anyone told valve to tidy that thing?
Comment 4 Daniel Scharrer 2014-05-12 17:46:40 UTC
> It's a steam bug, not a mesa one

I disagree: this (naïvely linking LLVM) is a change in mesa that breaks many binary software packages, not just Steam. While the steam-runtime will likely get a fix for this at some point, some older games may not be so lucky.

Packaging libstdc++ and libgcc_s is relatively common with binary software packages targeting Linux - it is practically required in order to target a wide range of distribution versions while not limiting yourself to an ancient compiler. Here is a small list of such packages that I happen to have installed which bundle those libraries:

$ find /{opt,usr/local/games}/ ~/Games/Trine/ -name 'libstdc++*' -o -name 'libgcc_s*'
/opt/intel/composerxe-2013.2.144/bin/sourcechecker/lib/intel64/pinruntime/libgcc_s.so
/opt/intel/composerxe-2013.2.144/bin/sourcechecker/lib/intel64/pinruntime/libstdc++.so
/opt/intel/composerxe-2013.2.144/bin/sourcechecker/lib/intel64/pinruntime/libstdc++.so.6
/opt/intel/composerxe-2013.2.144/bin/sourcechecker/lib/intel64/pinruntime/libstdc++.so.6.0.10
/opt/intel/composerxe-2013.2.144/bin/sourcechecker/lib/intel64/pinruntime/libgcc_s.so.1
/opt/intel/composerxe-2013.2.144/bin/sourcechecker/lib/ia32/pinruntime/libgcc_s.so
/opt/intel/composerxe-2013.2.144/bin/sourcechecker/lib/ia32/pinruntime/libstdc++.so
/opt/intel/composerxe-2013.2.144/bin/sourcechecker/lib/ia32/pinruntime/libstdc++.so.6
/opt/intel/composerxe-2013.2.144/bin/sourcechecker/lib/ia32/pinruntime/libstdc++.so.6.0.10
/opt/intel/composerxe-2013.2.144/bin/sourcechecker/lib/ia32/pinruntime/libgcc_s.so.1
/opt/quake4/libstdc++.so.6
/opt/quake4/libgcc_s.so.1
/usr/local/games/sacred/lib/lib1/libstdc++.so.6
/usr/local/games/sacred/lib/lib1/libgcc_s.so.1
/usr/local/games/x2/lib/lib1/libstdc++.so.6
/usr/local/games/x2/lib/lib1/libgcc_s.so.1
/usr/local/games/postalx/postal2game/System/libstdc++.so.5
/usr/local/games/postalx/postal2game/System/libgcc_s.so.1
/usr/local/games/postalx/postal1game/libstdc++.so.5
/usr/local/games/postalx/postal1game/libgcc_s.so.1
/usr/local/games/aquaria/libstdc++.so.6
/usr/local/games/aquaria/libgcc_s.so.1
/usr/local/games/lugaru/libstdc++.so.6
/usr/local/games/lugaru/libgcc_s.so.1
/usr/local/games/survivor/lib32/libstdc++.so.6
/usr/local/games/survivor/lib32/libgcc_s.so.1
/usr/local/games/shadowgrounds/lib32/libstdc++.so.6
/usr/local/games/shadowgrounds/lib32/libgcc_s.so.1
/usr/local/games/coldwar/lib/libstdc++.so.6
/usr/local/games/coldwar/lib/libstdc++.so.6.0.8
/usr/local/games/postal2/System/libstdc++.so.5
/usr/local/games/postal2/System/libgcc_s.so.1
/usr/local/games/braid/libstdc++.so.6
/usr/local/games/braid/libgcc_s.so.1
/usr/local/games/testtool/lib/lib1/libstdc++.so.6
/usr/local/games/testtool/lib/lib1/libgcc_s.so.1
/usr/local/games/prey/libstdc++.so.5
/usr/local/games/prey/libgcc_s.so.1
/home/dscharrer/Games/Trine/lib32/libgcc_s.so.1
/home/dscharrer/Games/Trine/lib32/libstdc++.so.6
/home/dscharrer/Games/Trine/lib64/libstdc++.so.6

This has not been a problem in the past as system libraries (those you effectively have to link against to make full use of the hardware) have refrained from pulling in either of the GCC libraries. In fact, the only one I found doing this besides mesa is XvMC:

$ for f in /lib/lib{dl,m,c,rt}.* /usr/lib/libasound* /usr/lib/libX* /usr/lib/libxcb* /usr/lib/mesa/* /usr/lib/opengl/{ati,xorg-x11}/lib/libGL* /usr/lib/libpulse* ; do ldd $f | grep -P '(libgcc|libstdc++)' | sed "s|^|$f: |" ; done
/usr/lib/libXvMCr600.so:        libstdc++.so.6 => /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.0-pre9999/libstdc++.so.6 (0x00007fb39b72e000)
/usr/lib/libXvMCr600.so:        libgcc_s.so.1 => /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.0-pre9999/libgcc_s.so.1 (0x00007fb39ae6c000)
/usr/lib/libXvMCr600.so.1:      libstdc++.so.6 => /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.0-pre9999/libstdc++.so.6 (0x00007f45d4a8f000)
/usr/lib/libXvMCr600.so.1:      libgcc_s.so.1 => /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.0-pre9999/libgcc_s.so.1 (0x00007f45d41cd000)
/usr/lib/libXvMCr600.so.1.0.0:  libstdc++.so.6 => /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.0-pre9999/libstdc++.so.6 (0x00007fc235d72000)
/usr/lib/libXvMCr600.so.1.0.0:  libgcc_s.so.1 => /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.0-pre9999/libgcc_s.so.1 (0x00007fc2354b0000)
/usr/lib/mesa/r200_dri.so:      libstdc++.so.6 => /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.0-pre9999/libstdc++.so.6 (0x00007ff45e80e000)
/usr/lib/mesa/r200_dri.so:      libgcc_s.so.1 => /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.0-pre9999/libgcc_s.so.1 (0x00007ff45df4c000)
/usr/lib/mesa/r300g_dri.so:     libstdc++.so.6 => /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.0-pre9999/libstdc++.so.6 (0x00007f69359b7000)
/usr/lib/mesa/r300g_dri.so:     libgcc_s.so.1 => /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.0-pre9999/libgcc_s.so.1 (0x00007f69350f5000)
/usr/lib/mesa/r600g_dri.so:     libstdc++.so.6 => /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.0-pre9999/libstdc++.so.6 (0x00007f37f0e61000)
/usr/lib/mesa/r600g_dri.so:     libgcc_s.so.1 => /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.0-pre9999/libgcc_s.so.1 (0x00007f37f059f000)
/usr/lib/mesa/radeon_dri.so:    libstdc++.so.6 => /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.0-pre9999/libstdc++.so.6 (0x00007f5528868000)
/usr/lib/mesa/radeon_dri.so:    libgcc_s.so.1 => /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.0-pre9999/libgcc_s.so.1 (0x00007f5527fa6000)
/usr/lib/mesa/radeonsi_dri.so:  libstdc++.so.6 => /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.0-pre9999/libstdc++.so.6 (0x00007f4021a96000)
/usr/lib/mesa/radeonsi_dri.so:  libgcc_s.so.1 => /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.0-pre9999/libgcc_s.so.1 (0x00007f40211d4000)
/usr/lib/mesa/swrast_dri.so:    libstdc++.so.6 => /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.0-pre9999/libstdc++.so.6 (0x00007f3bf7cc8000)
/usr/lib/mesa/swrast_dri.so:    libgcc_s.so.1 => /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.0-pre9999/libgcc_s.so.1 (0x00007f3bf7406000)
/usr/lib/mesa/swrastg_dri.so:   libstdc++.so.6 => /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.0-pre9999/libstdc++.so.6 (0x00007fd0b4263000)
/usr/lib/mesa/swrastg_dri.so:   libgcc_s.so.1 => /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.0-pre9999/libgcc_s.so.1 (0x00007fd0b39a1000)

This search includes fglrx's libGL by the way: The proprietary AMD (and I'm sure NVIDIA) drivers have long used C++ internally, but have taken care not to pollute the global namespace with the C++ standard library or GCC helper library. I think this shows even more precedent that these libraries should not be considered safe to use in base system libraries without additional precautions.

What you are doing here is introducing additional problems where none existed before. Please reconsider statically linking libLLVM and required C++/GCC libs into *_dri.so or finding some other solution to not conflict with programs loading libGL. (An even stricter RTLD_LOCAL that completely namespaces libs would be nice to have here …)

For reference, here are a few more bugs caused by this:
 #30192, #30901, #38182, #38783, #43964, #66955
Comment 5 Emil Velikov 2014-05-12 22:49:10 UTC
(In reply to comment #4)
> > It's a steam bug, not a mesa one
> 
> I disagree: this (naïvely linking LLVM) is a change in mesa that breaks many
> binary software packages, not just Steam. While the steam-runtime will
> likely get a fix for this at some point, some older games may not be so
> lucky.
>
I would say that both parties are to "blame" on this one. AFAICS the topic of to ship libgcc_s/libstdc++ or not has always been a interesting one.

[snip]
> What you are doing here is introducing additional problems where none
> existed before.
>
I beg to disagree here. Mesa has linked against libgcc_s and libstdc++ since forever. Whereas the static/shared linking against LLVM has always been a configure time decision.

> Please reconsider statically linking libLLVM and required
> C++/GCC libs into *_dri.so or finding some other solution to not conflict
> with programs loading libGL. (An even stricter RTLD_LOCAL that completely
> namespaces libs would be nice to have here …)
> 
Static linking against gcc/c++ seems like a bit of a pain as libtool, unconditionally appends "-lgcc -lgcc_s -lstdc++" (as defined by postdeps), thus -Wl,--static.. and/or -static-lib{gcc,stdc++} does not really help.

If you have any solid suggestion please put them forward.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.