So this is closable as not a Steam issue?
You tell me :) Maybe something has changed in open source stack to which Steam should be adjusted, I don't know, I'm not developer.
OpenGL is not working properly on your system. This is a system configuration problem and not something that Steam needs to change for. What exactly the problem with OpenGL is is not as simple to say, you'd need to check with the people maintaining it.
Opengl is properly working on my system.
Xonotic, Unigine benchmarks, few wine games, hey even few non-source Steam games do work.
Steam works too, just shows up error mentioned earlier. However TF2 (cba installing other source games) stopped working after todays update.
Issue is somewhere between git mesa, oibaf ppa and Steam/TF2, not my system per se. So perhaps at least try to do your f****** job and check with people maintaing mesa and oibaf ppa yourself. I'd be glad to provide any logs if needed.
You know, at Team Fortress 2 page there is a little penguin icon and I use system you guys recommend - Ubuntu. In other words, my config and hardware are supported. However I have to use third party PPA to get any good performance.
I'm a customer, I pay for your bills and if you say (which You do Valve) that my system is supported, I expect You to handle any communication and support issue between Valve, AMD and open source community.
Start treating Linux users same as OSX or Windows, instead of expecting us to investigate everything by ourselves. Not every Linux user is developer or sysadmin, not anymore.
I can't wait for other gaming platforms coming to Linux, cause You guys have no clue how to handle customers (do not mistake customers for community) or maybe just don't give a damn.
I'm sorry you're unhappy but you're getting the same support as you would get on OSX or Windows. If you installed a new AMD/NVIDIA/Intel driver on your Windows box and it broke Steam you'd get the same advice: follow up with AMD/NVIDIA/Intel. They own the code that caused the problem and they're the best people to investigate the problem.
Steam is a 32-bit app and the problem is likely some conflict between 32-bit OpenGL and 64-bit OpenGL components. 64-bit OpenGL apps will run fine, but if you get a 32-bit copy of glxinfo, for example, it will likely not have direct rendering either.
Yea, right.
After all it was Steam fault.
Removing (renaming) libgcc_s.so.1 from /home/maciej/.local/share/Steam/ubuntu12_32/steam-runtime/i386/lib/i386-linux-gnu fixed my issue.
I have no idea what I'm doing, yet it took me few minutes when I finally had time to sit on it and figure it out.
Thanks but no thanks. Great support like always.
For tracking purposes, duplicate of https://github.com/ValveSoftware/steam-runtime/issues/13.
I have the same problem with xorg-edgers... and it's also impacting dota2:
https://github.com/ValveSoftware/Dota-2/issues/1320
After deleting libgcc_s.so.1 everything works fine, so please reopen this issue.
This bug have been reported to Mesa-dev. And this is not a Mesa bug:
https://bugs.freedesktop.org/show_bug.cgi?id=78604
@gutigen and everyone else,
The problem comes from the fact that the binaries provided by your PPA are built against a newer version of libgcc than the steam-runtime ships, which is automatically loaded before running Steam. removing or renaming the steam-runtime library makes it fall back to the system default.
Now here's the thing, you're replacing key parts of your system with unstable git packages from an unofficial PPA. From that moment on you're no longer running standard Ubuntu, and Valve can't officially support your system anymore.
Valve can't test every possible system and neither can whoever maintains the Oibaf PPA build against current Ubuntu libraries, as well as the steam-runtime, so when you install these sort of packages it's up to you to keep that in mind that breakage might occur. If that's too much trouble, or "have no idea what you're doing", stick to the packages provided by the official repo's, because that's what Valve tests against.
File a bug report yeah, it's something the steam-runtime will have to deal with at some point anyway, but falling out against someone who, by the looks of it isn't even part of the actual Linux development team, isn't going to help out anyone.
For future notice, the steam-runtime is easily disabled by adding the STEAM_RUNTIME=0 variable before the steam command, in either the terminal or adding it to the .desktop Exec argument, as such:
$ STEAM_RUNTIME=0 steam
It should be one of the first things to check if you notice any error messages containing libraries in the steam-runtime directory.
Packages in the PPA are built against the standard libraries provided by Ubuntu. The problem is that Steam is, for some unclear reason, including older system libraries for its own use. The problem is Steam, indeed this happens not only with Ubuntu + PPA but also on Fedora and other systems.
@FabioPedretti
It caused problems on Arch as well, but neither are supported systems. The thing is uninstalling the PPA packages fixed the problem for gutigen, meaning the radeon packages in the Ubuntu repo are built against a lower version (14.04 seems to ship anywhere between 4.4 and 4.9).
And yeah, the steam-runtime is quite outdated, but the point of it isn't providing the latest and greatest libraries but to provide a uniform, stable base developers can build against without having to worry about which distro they're targeting.
Now I'm not saying Valve shouldn't update gcc, in fact they definitely SHOULD, and I would have opened a new ticket about it, except they're already working on it. I just have a problem with the way the @gutigen handled himself, or as it seems, any comment on a Valve related issue tracker.
a "Settings -> Advanced -> Don't override system libraries" should do a lot good than evil.
@ToostInc
You know, my reaction would be completely different if @gdrewb-valve acted like he cares. Small peak at my log was all I expected (for starters) from glorious Valve developers. You know, issue is right there, line 7 - issue with Steam runtime which have nothing to do with my system setup (which is suppose to be supported).
Perhaps it's time to stop praising Gaben and consider the idea that Valve customer support (don't mistake with community) is worse than EAs.
You make me laugh @gutigen . I'm amazed at your sheer persistance that you should get support for running a system that IS NOT SUPPORTED BY VALVE. Valve are breaking into new areas of Linux, they have been at this for about 15 months and you expect them to support your non-standard problems while also trying to port games, push out a new distro of their own and handle the 70~ million customers with only about 300 people in the company.
You are not entitled to anything. Steam is free. The games you buy are clearly stated to only run on Ubuntu and if they say otherwise, then that's not up to valve to support. Quite frankly @gdrewb-valve is amazingly supporting other operating systems regardless.
The best bit of your response is EA. I think you are better suited to them anyway to be honest. You can run a copy of Windows and just blissfully play their games because they arn't pushing any boundaries and releasing the same crap every year, which means less bugs for you. Also, you could run it in wine and see how they take you then ;).
If you did a bit of research you could acutally find out from the many sources how to disable the runtime
@gutigen
the issue also has nothing to do with the Steam client, which is what this particular tracker is for.
Had you taken the time to figure that out you would have gone to the correct issue tracker, and found out they're already working on it, instead of taking out another duplicate ticket in another place, although granted, you're far from the only one to make this mistake.
Also, you keep confusing bug tracking with customer support. This issue isn't caused by an error in the application, but by an oversight which is completely understandable.
No one can keep track and test against the thousands of system configurations and use-case scenarios possible, especially on Linux, that's what bugtracking is for: to find and fix anomalies caused by those infinite number of systems, use and misuse of the application. It is a reactionary process, and opening a ticket is notifying the developers of such an anomaly, not an open invitation to complaint.
And I'll say this again, but as soon as you install packages from unofficial PPA's, you deviate from the standard Ubuntu set-up, which, at that point, developers can not be held accountable for or test against. This is illustrated by the fact that, once you reinstalled the official packages found in your local repo, the issue was resolved, which is why @gdrewb-valve closed it.
If you install custom packages or choose to run a different distribution , it is your responsibility if that breaks compatibility with anything, asking Valve to contact the mesa project or, even worse, the PPA maintainer, for you is more than ridiculous.
@ToostInc
I agree. but like I've said, all I expected is @gdrewb-valve to give a f*** and at least take a look at my log instead of closing thread just to get rid of it. Action (or his inaction) -> reaction, simple as that. I don't get why is this so hard to understand, but hey w/e.
This is just one very small example of Valve not caring about their customers. If you dig deeper through all that Gaben and pcmasterrace nonsense, down there among facts about Valve you will find whole lot more of such bullshit.
I know this is a bug report and it's inappropriate to comment here without helping an issue but I wanted to apologize to @gdrewb-valve for the appalling behavior that @gutigen has demonstrated. Please don't let this case sour your feelings on Linux users.
@gdrewb-valve I won't go as far as @ainola in apologising for @gutigen 's .... interesting ... view on your responsibilities in supporting non-stock/supported operating systems, as no one but he is responsible for the things he has said. But I do agree with @ainola in the "Please don't let this case sour your feelings on Linux users." sentiment. Most Linux users I have talked to or seen online are more than willing to politely help debug an application, and don't assume to know more of developing than an actual dev.
@ainola @instantepiphany
Let me quote myself:
"Removing (renaming) libgcc_s.so.1 from /home/maciej/.local/share/Steam/ubuntu12_32/steam-runtime/i386/lib/i386-linux-gnu fixed my issue."
It was Steam fault since runtime was using outdated libraries and Oibaf PPA is built against those which you can find by default in so called "supported" Ubuntu 14.04. Heard that Valve is fixing the runtime now, which also proves that I was right (not to mention that I'm not the only person with this issue).
However, problem was not with this, but with @gdrewb-valve approach to whole affair, let me quote @gdrewb-valve :
"So this is closable as not a Steam issue?"
If he did took a small peak at log I provided in my first post, he would've noticed (as someone obviously more knowledgable in this area than me) where the problem is (right there, line 7), yet he chose to just not give f***.
If this was let's say Blizzard, this thread would looked completely different. But hey, Valve is known for terrible customer support (yes, bug tracker is part of customer support).
Why is this closed? I needed this freakin' workaround just to launch Source games. Unfortunately I can't run Source mods. Synergy isn't working because I get an error with OpenGL context "glGetError" something. I don't know, it flickers too much for me to actually copy and paste the error. But I'll bring it to the attention to the Synergy modders.
I'm literally having to share around scripts to fix this issue because any person running mesa 10.2 and actually hacking the steam runtime script to delete certain files. I appreciate that you have to cater for everybody but this is getting ridiculous.
#!/bin/bash
DIR=$HOME/.local/share/Steam/
echo "Removing libstd"
find $DIR -iname "libstd*" -exec rm -rf {} \;
echo "Removing libgcc"
find $DIR -iname "libgcc*" -exec rm -rf {} \;
echo "All Done"
@NothingMuchHereToSay @Half-Shot
This issue was closed because it's a steam-runtime problem, not a Steam Client one. People will be actually able to help you over here.
I worked on a solution for this issue yesterday.
please see it here:
http://askubuntu.com/questions/539858/ubuntu-14-04-could-not-find-required-opengl-entry-point-glgeterror/592692#592692
I have intel Q33 Chipset, I've also installed the latest version of the display driver but every time when i run dota 2 it gives me same error "could not find required opengl entry point"
What i'm doing wrong don't know
Switched to Ubuntu MATE, and was running into the r600 problem. The script @Half-Shot posted above fixed it, but I needed to run it a few times when Steam was updating itself.
As I still coming back here, I will share my solution, that survives steam updates:
Edit the file (with sudo) /usr/share/applications/steam.desktop and change the line 4 to:
Exec=env STEAM_RUNTIME=0 /usr/bin/steam %U
@Half-Shot clear and concise, thank you!
It seems the recent update of steam run-time reintroduced the issue - at least it worked all fine before.
Running it with STEAM_RUNTIME = 0 gives me:
You are missing the following 32-bit libraries, and Steam may not run:
libva.so.2
libbz2.so.1.0
libva.so.2
libva-x11.so.2
libva-1.8.3-1.el7.i686.rpm does not contain any libva.so.2 ... libbz2.so.1.0 and libva-x11.so.2 do not exist on CentOS at all. Just not certain if libva.so.2 might be provided by the NVidia UNIX driver installer - and not the driver package (which was the only recent system change).
When trying to revert to previous version:
cd $HOME/.local/share/Steam/ubuntu12_32/
mv steam-runtime ./steam-runtime.crap
mv steam-runtime.old ./steam-runtime
steam
it will extract the archive again and then gives me:
Forced use of runtime version for 32-bit libdbus-1.so.3. Host: 3.14.14 Runtime: 3.5.8
Forced use of runtime version for 32-bit libcurl.so.4. Host: 4.3.0 Runtime: 4.2.0
Forced use of runtime version for 32-bit libdbusmenu-glib.so.4. Host: 4.0.12 Runtime: 4.0.13
Found newer runtime version for 32-bit libgmp.so.10. Host: 10.2.0 Runtime: 10.3.0
Forced use of runtime version for 32-bit libgtk-x11-2.0.so.0. Host: 0.2400.31 Runtime: 0.2400.10
Found newer runtime version for 32-bit libidn.so.11. Host: 11.6.11 Runtime: 11.6.15
Found newer runtime version for 32-bit libogg.so.0. Host: 0.8.0 Runtime: 0.8.2
Found newer runtime version for 32-bit libstdc++.so.6. Host: 6.0.19 Runtime: 6.0.21
Found newer runtime version for 32-bit libvorbis.so.0. Host: 0.4.6 Runtime: 0.4.8
Found newer runtime version for 32-bit libvorbisenc.so.2. Host: 2.0.9 Runtime: 2.0.11
Found newer runtime version for 32-bit libvorbisfile.so.3. Host: 3.3.5 Runtime: 3.3.7
Found newer runtime version for 64-bit libGLU.so.1. Host: 1.3.1 Runtime: 1.3.8004
Forced use of runtime version for 64-bit libcurl.so.4. Host: 4.3.0 Runtime: 4.2.0
Found newer runtime version for 64-bit libdbusmenu-glib.so.4. Host: 4.0.12 Runtime: 4.0.13
Found newer runtime version for 64-bit libdbusmenu-gtk.so.4. Host: 4.0.12 Runtime: 4.0.13
Found newer runtime version for 64-bit libgmp.so.10. Host: 10.2.0 Runtime: 10.3.0
Found newer runtime version for 64-bit libidn.so.11. Host: 11.6.11 Runtime: 11.6.15
Found newer runtime version for 64-bit libmpg123.so.0. Host: 0.44.5 Runtime: 0.44.8
Found newer runtime version for 64-bit libogg.so.0. Host: 0.8.0 Runtime: 0.8.2
Found newer runtime version for 64-bit libopus.so.0. Host: 0.5.2 Runtime: 0.7.0
Found newer runtime version for 64-bit libstdc++.so.6. Host: 6.0.19 Runtime: 6.0.21
Found newer runtime version for 64-bit libvorbis.so.0. Host: 0.4.6 Runtime: 0.4.8
Found newer runtime version for 64-bit libvorbisenc.so.2. Host: 2.0.9 Runtime: 2.0.11
Found newer runtime version for 64-bit libvorbisfile.so.3. Host: 3.3.5 Runtime: 3.3.7
vainfo output:
libva info: VA-API version 0.40.0
libva info: va_getDriverName() returns 0
libva info: Trying to open /usr/lib64/dri/nvidia_drv_video.so
libva info: Found init function __vaDriverInit_0_40
libva info: va_openDriver() returns 0
vainfo: VA-API version: 0.40 (libva )
vainfo: Driver version: Splitted-Desktop Systems VDPAU backend for VA-API - 0.7.4
vainfo: Supported profile and entrypoints
...
Hello,
I am facing problems when trying to play Mount&Blade Warband on Steam, i.e Steam launches without problems but the game mentioned above is not launching when pressing the play button. (I am able to launch and play other games.)
My operating system is Ubuntu 20.04.1 LTS. I am total newbie to Linux but willing/trying to learn more. I read a lot about the problem I am having with launching the game and these are the things that I tried so far:
Non of them solved the problem. Still when pressing the play button it tries to launch for a second and then nothing happens.
Any advice/answer would be highly appreciated. Thanks!
https://gist.github.com/gutigen/1906a47bc63bf82f4a8f
Files Steam fails to loads are all there (checked). Tried adding my user to video group.
Ubuntu 14.04 64bit with Oibaf PPA (have to use it for optimal performance).
It started happening after updating my system today (I do that manually every few days with dist-upgrade). Unigine Benchmarks and non-source games work like before.
EDIT:
I reverted back to stack from Ubuntu repo (with ppa-purge) and problem is gone, so I guess there is something wrong with packages from Oibaf PPA.