Support non-multilib x86_64 setups

[PureTryOut]

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.

[stephanlachnit]

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). What would be possible is a "no-multilib"-option, unlocking all options anyway, however I don't think it should be default (consider that Steam only provides 32bit binaries).

[PureTryOut]

Lutris runs just fine on amd64 setups with 32bit multilib

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?

[stephanlachnit]

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. And enabling for example gamemoderun anyway even if the 32 bit lib isn't installed will cause unnecessary bug reports.

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.

[strycore]

Having a 64 bit only system is a good way to not be able to run any game at all.

[PureTryOut]

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?

[strycore]

Fine, let's talk. For me, removing 32bit multilib equates to the death of all 32bit applications. Apple did it and they didn't have a 32 bit compatibility layer and now their 32bit software ecosystem is no longer executable on modern hardware. The way Canonical seemed to do things looked a lot like that too.

There are just so many things that are dependent on a 32 bit layer being here. I'm mostly concerned about graphics drivers though. It's nice to have the ability to run 32bit code in Flatpak or Docker for example but containers aren't going to ship kernel drivers so how 32bit GL and Vulkan drivers going to be available?

[PureTryOut]

but containers aren't going to ship kernel drivers so how 32bit GL and Vulkan drivers going to be available?

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.

[strycore]

I don't have a full understanding of this either. This is why I'm hostile to anyone even suggesting removal of 32bit layers. The way Canonical did it shows they didn't have a clear understanding either, they were just eager to remove the architecture because it's too much work for them to maintain. And Apple just didn't care.

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.

[eszlari]

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.

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:

sudo apt install flatpak
flatpak remote-add flathub https://flathub.org/repo/flathub.flatpakrepo
flatpak remote-add flathub-beta https://flathub.org/beta-repo/flathub-beta.flatpakrepo
flatpak install lutris
flatpak install org.freedesktop.Platform.GL32.nvidia-xxx-xx (see flatpak --gl-drivers)
flatpak install org.freedesktop.Platform.GL32.default (for mesa drivers)
flatpak install org.gnome.Platform.Compat.i386

flatpak run net.lutris.Lutris

[Saroufim]

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?

[strycore]

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.