-
Notifications
You must be signed in to change notification settings - Fork 0
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
Support non-multilib x86_64 setups #38
Comments
Lutris runs just fine on amd64 setups with 32bit multilib, however you can't use stuff like gamemoderun since Lutris doesn't check whether the game is 32 or 64 bit (correct me if I'm wrong). |
Well yes, but I'm talking about non-multilib systems. Why should it be an option, rather than automatically doing the things required to make it work? |
Since that requires a huge amount of work. Lutris is intended for "throw a game at me and I make it work", and that just isn't the case without 32bit support (sadly). Adding checks to figure out whether the missing 32bit support is intentional or not is just to much effort for something that isn't really inside the scope of Lutris. By adding an option for users that really don't want any 32 bit software can use some more features of Lutris, and the other users will still be pointed out to missing software, without requiring a ton of code. |
Having a 64 bit only system is a good way to not be able to run any game at all. |
That is honestly a short-sighted argument, and will cause you problems in the future. There are multiple ways to run 32-bit stuff on 64-bit only hosts, I play my Steam games fine for example. Alpine Linux might not be a distribution you care for, but Ubuntu probably is. Did you forget they tried to get rid of multilib already? They reverted their changes after a lot of backlash, but they will undoubtedly try again in the future. Why not be prepared for this? |
Fine, let's talk. There are just so many things that are dependent on a 32 bit layer being here. |
I'll be honest, I don't fully know how this works. But I can most definitely say I can run 32-bit Steam games perfectly fine in the Steam Flatpak, on my system which is most definitely 64-bit only. I'm guessing the 32-bit userland drivers are installed in one of the runtime layers Flatpak offers, which makes it work. There is no such thing as a 32-bit kernel driver, even on a multilib 64-bit systems. It seems the userland drivers don't care what bit kernel you are running. |
I don't have a full understanding of this either. This is why I'm hostile to anyone even suggesting removal of 32bit layers. Our number 1 response to people having issues running games is "have you installed 32bit Vulkan libs" or "do you have 32bit Wine". And most of the time they do not. And most of the time, adding the missing 32bit component will fix things. |
You could avoid this by embracing flatpak as the primary distribution mechanism for Lutris. People could just install Lutris from Flathub and would have all the same/identical working setup out of the box. At the moment, manual work is necessary, because Lutris is only in the Flathub Beta repository:
|
Just tossing an idea here but Lutris requires a lot of libraries to be fully functional. What about a docker image with all the necessary bits and pieces? |
I've started experimented with the idea and so far I've ran Jamestown and Doom 3 native. I'm still having issues with a lot of games. |
Currently Lutris seems to expect an x86_64 system to always be capable of running 32-bit programs, while this is not always the case. For example Gentoo Linux has an option to install as pure 64-bit, and Alpine Linux supports both x86_64 and x86 but not multilib. Besides, distributions like Ubuntu have already shown they like to get rid of multilib as well.
There are several ways of solving this, for example by installing stuff into Flatpaks, chroots or even Docker (assuming the kernel has been configured to be able to execute 32-bit programs on 64-bit). Preferably Lutris would realize itself the system is not capable of running 32-bit programs, and automatically install stuff in a compatible way when required.
The text was updated successfully, but these errors were encountered: