-
Notifications
You must be signed in to change notification settings - Fork 44
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
Steam ebuild should have glibc[stack-align] as a USE flag requirement #321
Comments
It must have been something else. I only know of about 4 games where it makes a difference. |
The only thing I had changed on my system was that single flag. Nothing worked before, Steam would try to start a game and immediately close it. Once changed, everything worked after. Have you tested this yourself? I don't have the ability to make a video of a before and after, so I'm not sure how I could give you any sort of proof other than to try it yourself? |
I implemented this USE flag, so I think I'd know, unless something has changed since. Especially as we lived without this flag for years and nearly everything worked fine! Were any of the native games 64-bit? Can you give some examples? |
Yeah I don't really recall the flag ever being a thing and don't remember when it was implemented. All I know is that one day Steam stopped working for me and the only reason I came across this is because Steam Beta's -gamepadui was giving me a segfault error with glibc and I decided to check a default install vs my custom flags. I've already double tested this and recompiled glibc multiple times. I have over 700 games in my library, I don't know which exactly are 32 bit vs 64 bit but any game I tried didn't work. I will do this one more time and try a random set of games, but if you any in particular in mind that I might have I will test it. |
I've tested: 140 (Native) I can pick any random game and it won't start up at all. As you can see, that list has both native, Proton, and 32 bit vs 64 games on it. Soon as the flag is compiled in, things work fine. I'm recompiling the flag back in now. If it helps, I have an AMD Ryzen 3950X, a RTX 3070 using proprietary drivers and a Plasma Wayland desktop. I've tried both Wayland and X11 sessions which doesn't make a difference. I've tried Zink on Nvidia, native OpenGL, DXVK, WineD3D, anything. The only thing that changes things is the USE flag stack-realign. |
I don't have any of those installed through Steam, but I do have Shovel Knight installed from GOG, and it is 64-bit. The thing is this flag literally does nothing to 64-bit binaries. All it does is add a single compile flag to the 32-bit build of glibc. I'll see whether I can reproduce this anyway, but exactly which games this affects does vary between systems, as it depends on a lot of factors. I have a similar environment to you, save for the NVIDIA card.
|
Steam is still 32 bit though, so I'm wondering if it's something within the steam launcher itself that is relying on the flag. I don't think it's the games themselves but I don't have any non-steam games currently installed to try, and no time to test that scenario. I really think they'd be fine and this isn't related to that.
|
I still haven't been able to reproduce this with the Steam beta and at least when forcing a different glibc with this:
I notice you're using clang. I can't tell whether glibc has been built with this (you need I'm at a loss. I'll leave this open in case anyone else hits it. |
glibc is still built with gcc and bfd. One of the 2.35 patch sets broke building glibc with LLD, and AFAIK it's never been able to be built with Clang although work is being done on that. I'll post about this on r/gentoo and see if I can find anyone to reproduce it. Thank you for your time. |
Hello, I finally have my equipment set back up so I was able to do some testing. I'm still using GCC 11.3.1 as you could see from my emerge ---info. I did several glibc builds.
Apparently, -ftree-vectorize which is enabled in -O3 and higher, kills Steam's binaries used to launch games as posted by a user in my reddit thread. You can also see on the Steam bugtracker here how the code used to launch games is stack aligned differently. Sam from the Gentoo team mentioned: "Note that in Gentoo, we've worked around this by adding a USE=stack-realign USE flag to the sys-libs/glibc and sys-libs/ncurses ebuilds." Soon -ftree-vectorize will be the default for -O2 so even if the user doesn't have USE="custom-cflags" this will be a problem. IMO, steam ebuild should require glibc[stack-realign] since -ftree-vectorize works with the flag enabled and this is soon to be default behavior. It isn't just an issue for a handful of games, it's an issue for the gameoverlayrenderer and reaper binary. |
What setup gives the best performance? |
Just adding some info about this issue. I am pretty sure this bug ValveSoftware/Source-1-Games#3727 and https://wiki.gentoo.org/wiki/Steam/Games_troubleshooting#Half-Life_2 is the issue here. I created an env file only one line, "CFLAGS_x86="${CFLAGS_x86} -mstackrealign" and only point glibc to it. Nothing else is required to fix the 32bitaliment bug with the steam client. UPDATE: The above hacks are no longer needed as USE flag stack-realign was added some time ago. gentoo/gentoo@02aa632 The USE flag stack-realign is only applied to the 32bit build of glibc, so there is no performance decrease on 64-bit builds. The only binaries left that are 32-bit is mostly older games and they don't suffer a performance penintly due to hardware back then was 10 times slower then the 64-bit hardware use today. |
Right, but that flag already existed when this thread was opened. |
I'm fairly certain it's a default USE flag, but I'm an idiot who likes to ignore such things. My system is currently built with somewhat minimal USE flags. The USE flag stack-align was disabled because of the supposed performance costs of leaving it enabled. Turns out with it disabled it seems Steam can't start any games. No proton games, no native games, nothing. Soon as the flag was turned back on, games started working again.
STEAM_RUNTIME on or off doesn't seem to make a difference, either.
Yeah I doubt there is many people this would affect but I figured if Steam isn't going to work with it off the ebuild should force it as a dependency for ding dongs like me.
The text was updated successfully, but these errors were encountered: