As an update to the situation around Canonical planning to drop 32bit support (and Valve saying bye-bye to Ubuntu 19.10+ support), apparently they're not. Instead, the 32bit libraries will be frozen. Are you confused yet? I sure am.
Canonical's Steve Langasek has attempted to clarify the situation. Here's what they said:
I’m sorry that we’ve given anyone the impression that we are “dropping support for i386 applications”. That’s simply not the case. What we are dropping is updates to the i386 libraries, which will be frozen at the 18.04 LTS versions. But there is every intention to ensure that there is a clear story for how i386 applications (including games) can be run on versions of Ubuntu later than 19.10.
That's at least a little better, isn't it? They also said a little further:
[…] since the vast majority of i386-only software is also legacy (closed-source, will never be rebuilt), it also does not generally benefit from newer libraries […]
There's a pretty big difference from not being "included as an architecture", to having them available but frozen and still possible to use, isn't there? It's confusing, since that's not how it was originally explained. This is something that should have been said very clearly from the start.
Perhaps this might not be the epic disaster many people (myself included) thought it might turn out to be. We still have to wait and see how exactly they implement all this, and how it will affect gaming.
There's still going to be confusion and issues though, like upgrading drivers. Touching on that, Langasek said:
32-bit mesa will be available in the Ubuntu 18.04 repository. Note that mesa already gets updates in 18.04 which track the versions from later Ubuntu releases, as part of hardware enablement. If incompatibilities are introduced beyond 20.04 (which is the cutoff for hardware enablement backports for 18.04), we will need to address them on a case-by-case basis.
So it sounds like you're still going to be stuck in some ways. Seems like the proposal is still no good for Wine either (and so Steam Play too).
Article taken from GamingOnLinux.com.
Quoting: x_wingQuoting: Shmerl2. Come up with solution to run 32-bit programs, using 64-bit libraries with good performance, no 32-bit libs involved at all.
That's not a solution for graphic intensive applications, and probably every library in your system because in order to map a 32 bit library into the 64 bit version you will have to start a new process that handles the library calls through an IPC with a big impact in the performance.
Using processor emulation like with Qemu would be indeed too much of performance hit. But hardware gets better, solutions get better and etc. Eventually this might work with acceptable performance. 32-bit games will remain old, so their level of performance requirements will be easier and easier to crunch. But not today, and besides no one implemented that yet.
Last edited by Shmerl on 24 June 2019 at 12:49 am UTC
Luke_Nukem Jun 24, 2019
No. Issues. At. All.
But this doesn't solve HumbleBumble or GOG. Though I do seem to recall and automated GOG->flatpak creator?
Quoting: ShmerlQuoting: x_wingQuoting: Shmerl2. Come up with solution to run 32-bit programs, using 64-bit libraries with good performance, no 32-bit libs involved at all.
That's not a solution for graphic intensive applications, and probably every library in your system because in order to map a 32 bit library into the 64 bit version you will have to start a new process that handles the library calls through an IPC with a big impact in the performance.
Using processor emulation like with Qemu would be indeed too much of performance hit. But hardware gets better, solutions get better and etc. Eventually this might work with acceptable performance. 32-bit games will remain old, so their level of performance requirements will be easier and easier to crunch. But not today, and besides no one implemented that yet.
And will never be an option having the retro compability at hardware level. Also, creating such emulation layer stills requires to have the 32 bit libraries to run, so not a solution for the current problem.
Last edited by x_wing on 24 June 2019 at 12:57 am UTC
Nevertheless Jun 24, 2019
Quoting: Luke_NukemI just purged all *386 libs from my install, including Steam. Then installed Steam via flatpak...
No. Issues. At. All.
But this doesn't solve HumbleBumble or GOG. Though I do seem to recall and automated GOG->flatpak creator?
True! Though it is possible to install and play GOG games via "Install non Steam game" function in flatpak Steam - even Windows GOG games via Proton. Not the perfect solution, but works!
Quoting: Luke_NukemI just purged all *386 libs from my install, including Steam. Then installed Steam via flatpak...
No. Issues. At. All.
But this doesn't solve HumbleBumble or GOG. Though I do seem to recall and automated GOG->flatpak creator?
And what about proton games? Do they work without problems?
Nevertheless Jun 24, 2019
Quoting: x_wingQuoting: Luke_NukemI just purged all *386 libs from my install, including Steam. Then installed Steam via flatpak...
No. Issues. At. All.
But this doesn't solve HumbleBumble or GOG. Though I do seem to recall and automated GOG->flatpak creator?
And what about proton games? Do they work without problems?
I have no problems at all.
Quoting: x_wingAnd will never be an option having the retro compability at hardware level. Also, creating such emulation layer stills requires to have the 32 bit libraries to run, so not a solution for the current problem.
32-bit libraries can be completely bypassed, by modifying 32-bit code on the fly in some way, into 64-bit one. Something like thunking idea: https://en.wikipedia.org/wiki/Thunk
Not sure how well that would work, but hard to say until someone tries.
Last edited by Shmerl on 24 June 2019 at 1:13 am UTC
Quoting: ShmerlQuoting: x_wingAnd will never be an option having the retro compability at hardware level. Also, creating such emulation layer stills requires to have the 32 bit libraries to run, so not a solution for the current problem.
32-bit libraries can be completely bypassed, by modifying 32-bit code on the fly in some way, into 64-bit one. Something like thunking idea: https://en.wikipedia.org/wiki/Thunk
Not sure how well that would work, but hard to say until someone tries.
But what if you have a code that plays around with pointer size values? Is a call for disaster that. Also, you have to support all the code required to translate your 32 bit app to 64 bit just to avoid building the required deps in 32 bits. Having the support at hardware level and libraries that can be compiled for 32 bit is a no brainer decision.
In short, all the suggested workarounds are by far more expensive than simply compiling the base deps for x86.
Quoting: x_wingIn short, all the suggested workarounds are by far more expensive than simply compiling the base deps for x86.
They might be more expensive to develop, but it can be better than having nothing when upstream libraries simply decide to drop 32-bit support to begin with. They can do it at some point. Then what?
Last edited by Shmerl on 24 June 2019 at 2:03 am UTC
Quoting: ShmerlThey might be more expensive to develop, but it can be better than having nothing when upstream libraries simply decide to drop 32-bit support to begin with. They can do it at some point. Then what?
In the moment that any library drops 32-bit support (which is kinda debatable as x86 and AMD64 are a very related instruction set) you just freeze to the last version of the library that is supported. Basically, what Ubuntu says are going to do now but with the problem that they are doing this before any common library got into such "milestone".
Last edited by x_wing on 24 June 2019 at 2:12 am UTC
Patreon
PayPal
See more from me