Intel 32bit packages on Ubuntu from 19.10 onwards

Please don’t overreact. Those pointed were addressed in the FAQ. They are available solutions you can use today and we are talking to Valve trying to make sure Steam keeps working out of the box for 19.10.

1 Like

I an not exaggerating. Steam is not only source of such software. What about GOG or self published games outside steam? And Valve devs already said that fixing this will be tractable but will need involved work that will get in the way of feature and performance improvements.

There is a lot of none gaming software that is in use still that none will be able to take the time to make compatible. And the solutions presented as “solutions” are messy and not suitable for a new users that want simplicity in their workflow. Seasoned users will not be affected sure. But if you want the desktop to survive the marketshare needs to increase. And creating such hurdles does not help adoption.


The 64-bit version of Wine can run 99% of 32-bit Windows software that its 32-bit counterpart can, in the same way that a 64-bit Windows version can run most 32-bit Windows software. If you have created a clean Wine prefix in the past years, chances are you are already using a 64-bit Wine with your 32-bit software (if there is a folder called “Program Files (x86)” in your wine C drive, you are running a 64-bit version of Wine).

That is half true.
Current you need install wine32:i386 for running win32 on a 64bit wine/system.


Which distributions have already fully dropped i386 support?

Even RHEL 8 still provides i386 compat libraries.

Available Packages
Name         : glibc
Version      : 2.28
Release      : 54.el8
Arch         : i686
Size         : 3.7 M
Source       : glibc-2.28-54.el8.src.rpm
Repo         : rhel-8-baseos
Summary      : The GNU libc libraries
URL          :
License      : LGPLv2+ and LGPLv2+ with exceptions and GPLv2+ and GPLv2+ with exceptions and BSD and Inner-Net and ISC and Public Domain and GFDL
Description  : The glibc package contains standard libraries which are used by
             : multiple programs on the system. In order to save disk space and
             : memory, as well as to make upgrading easier, common system code is
             : kept in one place and shared between programs. This particular package
             : contains the most important sets of shared libraries: the standard C
             : library and the standard math library. Without these two libraries, a
             : Linux system will not function.

Pop!_OS has never supplied 32-bit installation media, so the impact on our users will be very minimal. The biggest outlier is likely Steam, which should be fixed within Ubuntu (and Pop! by proxy) by 19.10.


Ubuntu has never supported a 32-bit UEFI GRUB, and regardless, this is orthogonal to the question of providing 32-bit userspace packages.

It only requires pre-compiled binary. So all you is that or you can compile on 18.04.

No, that’s totally wrong


Tell the same to propriety 32 bit application/drivers

Which distributions have already fully dropped i386 support?
Even RHEL 8 still provides i386 compat libraries.

Libraries, or just the libc library?

Note, Ubuntu too provides cross-compiled libc6 for 32bit on amd64, specifically:

$ apt show libc6-i386:amd64
Package: libc6-i386
Version: 2.29-0ubuntu2
Priority: optional
Section: libs
Source: glibc
Origin: Ubuntu
Maintainer: Ubuntu Developers <>
Original-Maintainer: GNU Libc Maintainers <>
Installed-Size: 13.9 MB
Depends: libc6 (= 2.29-0ubuntu2)
Conflicts: libc0.1-i386, libc6-amd64, libc6-i386:x32, libc6-mips32, libc6-mips64, libc6-mipsn32, libc6-powerpc, libc6-ppc64, libc6-s390, libc6-sparc, libc6-sparc64, libc6-x32:i386
Replaces: libc6-dev-i386
Supported: 9m
Download-Size: 2,658 kB
APT-Manual-Installed: no
APT-Sources: eoan/main amd64 Packages
Description: GNU C Library: 32-bit shared libraries for AMD64
 This package includes shared versions of the standard C
 library and the standard math library, as well as many others.
 This is the 32bit version of the library, meant for AMD64 systems.

But that is not libc6:i386 from the i386 archive. RHEL8 supports only amd64 arm64 ppc64el s390x (using dpkg arch tags). Ubuntu supports all of those and armhf.

I do not have access to RHEL8, do you have a list of any other Arch: i686 rpms that they provide prebuilt?

Most games bundle all of their runtime dependecies and do not need Ubuntu’s i386 libraries.

Specifically w.r.t. accessing host graphics drivers, those will be provided for i386 access on amd64 host in an improved manner than done today. That does not imply carrying all of i386 Ubuntu archive.

It would be best to fix up wine64 to be able to run those applications, or use the container solutions to use win32 with bionic’s i386 libraries on an otherwise 19.10+ amd64 host.

The set of libraries needed to run wine32 “just from the archive” is not in fact small. It’s majority of ubuntu main unfortunately due to very long tail of X / graphics / sound / gtk stack runtime, build and test time dependencies. And it’s a not a one-off task, but ongoing maintenance is required.

I do wonder if wine32 classic snap might be a viable technical solution here.

1 Like

Not in my experience. Games tend to bundle middleware down to the level of SDL, but the dependencies beyond that come from the host. That’s why Steam created their runtime in the first place.


First, note that 32-bit software does not work today on Ubuntu amd64 without installing additional dependencies. While Ubuntu ships with the 32-bit archive enabled, there are no compatibility libraries installed by default. There is no reason in principle that the solutions provided going forward can’t be equally as usable as what exists today.

Second, nothing in the solution described in is specific to steam except the name. This profile exposes the standard set of interfaces into the container that are needed to run graphical games, regardless of their source. And with a bit of effort this cycle, we can expect the instructions to be greatly simplified vs what is currently shown there.

If we do setup a LXD container for Steam, can it still access the entire /home directory?

My games are spread across multiple drives

1 Like

Details to be determined, but in principle yes, we would want this container to have access to /home.

Its a lot more than just glibc, there are 1250 i686 rpms in RHEL 8.0, pretty much a full set of libraries.

RHEL 8 i686 rpms


I agree with this.

I think the best road is to create a library loader that translate from x86 calls to x86-64 library.
Disclaimer: I don’t know that the idea work with my limit knowledge of loading Linux librarys.
EDIT: i think this idea is good idea for loading 32bit Steam/GOG games

Dropping support for i386 hardware and installation: Fine!
Dropping support for i386 applications: Likely going to be a mess!

And no, requiring people to run containers and VMs with old OS’s does not count as “supported”. That is exactly why we have DOSbox, WINE etc; to be able to run decades old software on our fresh OS’s.

Hopefully a smoother solution is found than LXD. It might be OK to encapsulate i386 to using an older subset of libraries. However this should be supported way beyond the support period of 18.04.

Maybe using Debian i386 libraries is a solution?

But prodding developers to getting their apps to 64-bit now(!) is a good thing :slight_smile: