Valve employees have at the very least called out glibc and mesa drivers as required 32 bit libraries.
1 Like
Add pipewire for sure, and then the client at the very least also needs network manager.
1 Like
It was pointed out that these are needed for the Asahi FEX usecase:
glibc-devel.i686
glibc-devel.x86_64
kernel-headers.x86_64
libstdc+Ā±devel.x86_64
2 Likes
This may be reductive, but it seems to me that the libraries valve wonāt provide are the lowest level ones (pipewire, glibc, mesa, and so on). We could work backwards from that.
(Ran on Arch, so might not the exact same, but given the Steam binary is shipped by Valve themselves, Iād imagine it be similar)
> lsof | grep -i steam | grep lib32 | grep -o '[^ ]*$' | sort -u
/usr/lib32/gconv/gconv-modules.cache
/usr/lib32/ld-linux.so.2
/usr/lib32/libblkid.so.1.1.0
/usr/lib32/libbrotlicommon.so.1.1.0
/usr/lib32/libbrotlidec.so.1.1.0
/usr/lib32/libbz2.so.1.0.8
/usr/lib32/libcap.so.2.76
/usr/lib32/libc.so.6
/usr/lib32/libdbus-1.so.3.38.3
/usr/lib32/libdl.so.2
/usr/lib32/libdrm_amdgpu.so.1.125.0
/usr/lib32/libdrm_intel.so.1.125.0
/usr/lib32/libdrm.so.2.125.0
/usr/lib32/libelf-0.193.so
/usr/lib32/libexpat.so.1.10.2
/usr/lib32/libffi.so.8.2.0
/usr/lib32/libfontconfig.so.1.15.0
/usr/lib32/libfreetype.so.6.20.2
/usr/lib32/libgallium-25.1.4-arch1.1.so
/usr/lib32/libgcc_s.so.1
/usr/lib32/libgio-2.0.so.0.8400.3
/usr/lib32/libGLdispatch.so.0.0.0
/usr/lib32/libglib-2.0.so.0.8400.3
/usr/lib32/libGL.so.1.7.0
/usr/lib32/libGLX_mesa.so.0.0.0
/usr/lib32/libGLX.so.0.0.0
/usr/lib32/libgmodule-2.0.so.0.8400.3
/usr/lib32/libgobject-2.0.so.0.8400.3
/usr/lib32/libharfbuzz.so.0.61121.0
/usr/lib32/libicudata.so.76.1
/usr/lib32/libicuuc.so.76.1
/usr/lib32/libLLVM.so.20.1
/usr/lib32/liblzma.so.5.8.1
/usr/lib32/libmount.so.1.1.0
/usr/lib32/libm.so.6
/usr/lib32/libnm.so.0.1.0
/usr/lib32/libnsl.so.1
/usr/lib32/libnspr4.so
/usr/lib32/libnss3.so
/usr/lib32/libnss_myhostname.so.2
/usr/lib32/libnss_mymachines.so.2
/usr/lib32/libnss_resolve.so.2
/usr/lib32/libnssutil3.so
/usr/lib32/libpciaccess.so.0.11.1
/usr/lib32/libpcre2-8.so.0.14.0
/usr/lib32/libpipewire-0.3.so.0.1405.0
/usr/lib32/libplc4.so
/usr/lib32/libplds4.so
/usr/lib32/libpng16.so.16.49.0
/usr/lib32/libpthread.so.0
/usr/lib32/libresolv.so.2
/usr/lib32/librt.so.1
/usr/lib32/libsensors.so.5.0.0
/usr/lib32/libsmime3.so
/usr/lib32/libSPIRV-Tools.so
/usr/lib32/libstdc++.so.6.0.34
/usr/lib32/libsystemd.so.0.40.0
/usr/lib32/libudev.so.1.7.10
/usr/lib32/libuuid.so.1.3.0
/usr/lib32/libva.so.2.2200.0
/usr/lib32/libX11.so.6.4.0
/usr/lib32/libX11-xcb.so.1.0.0
/usr/lib32/libXau.so.6.0.0
/usr/lib32/libxcb-dri3.so.0.1.0
/usr/lib32/libxcb-glx.so.0.0.0
/usr/lib32/libxcb-present.so.0.0.0
/usr/lib32/libxcb-randr.so.0.1.0
/usr/lib32/libxcb-render.so.0.0.0
/usr/lib32/libxcb-res.so.0.0.0
/usr/lib32/libxcb-shm.so.0.0.0
/usr/lib32/libxcb.so.1.1.0
/usr/lib32/libxcb-sync.so.1.0.0
/usr/lib32/libxcb-xfixes.so.0.0.0
/usr/lib32/libXdmcp.so.6.0.0
/usr/lib32/libXext.so.6.4.0
/usr/lib32/libXfixes.so.3.1.0
/usr/lib32/libXinerama.so.1.0.0
/usr/lib32/libxml2.so.16.0.4
/usr/lib32/libxshmfence.so.1.0.0
/usr/lib32/libXss.so.1.0.0
/usr/lib32/libXxf86vm.so.1.0.0
/usr/lib32/libz.so.1.3.1
/usr/lib32/libzstd.so.1.5.7
1 Like
Suppose that Fedora matches what RHEL 10 and Alma 10 are doing. In addition to not distributing any 32 bit libraries or executables, do you know if the RHEL 10 kernel still has support for running 32 bit executables? I think that 32 bit support has to be built in with CONFIG_IA32_EMULATION=y and canāt be added later as a loadable module.
I may be incorrect, but aside from the X11 libraries these are all what could be considered ālow levelā right?
You may need to run it with ia32_emulation=true (Chapter 4. Important changes to external kernel parameters | 10.0 Release Notes | Red Hat Enterprise Linux | 10 | Red Hat Documentation); otherwise, it is available.
1 Like
Not really sure - I donāt tend to use terms like ālow levelā in regards to libraries. To me a library is just a library. This might be terminology that others use though.
I cannot speak for what RHEL does. However, regardless of the outcome of this particular proposal, I would hope / suggest that Fedora leaves that option on for their kernel builds. Simply leaving that config option on during compilation does not introduce the same level of maintenance burden that actually maintaining 32bit libraries does, so I would imagine this would be uncontroversial.
2 Likes
I canāt speak for the RHEL/Fedora teams, but I find it extremely unlikely that this will be removed. AFAIK for distributions, this presents pretty much zero additional work.
It is often recommended to disable this option for security reasons, as it removes another attack surface. However, since kernel 6.6, it is possible to enable or disable this at runtime using the ia32_emulation parameter, and there is CONFIG_IA32_EMULATION_DEFAULT_DISABLED to disable it by default, which is ideal for hardened configurations. Those who still need it can enable it when necessary.
So, in my opinion, this option is here to stay, which makes container-based solutions interesting, as they still allow users to run legacy software with a legacy runtimes, even if their distribution drops 32-bit support completely.
1 Like
i Just ran the steam installation from tarballā¦on a system with no i686..
I had to satify 3 libraries to make the installer happy.
libGL.so.1
libdrm.so.2
libnsl.so.1
that resulted in 35 i686 packages being installed on this system
Running the steam installer.. i get to the steam login screen.
Using pldd for the running executables to explore the runtime library depsā¦
The pipewire librarry dep is picked up from the steam provided bundle.
I see no library dep on networkmanager afaict in any of the running binaries.
previews in the store play with sound.
I downloaded a couple of the free to play linux games they load up into start screens fine for me.
What am I missing? Why canāt we rely on the bundled libraries?
3 Likes
Could it be handled within Fedora gaming documentation :: Fedora Docs SIG and not yet existing Toolchain development SIG?
However, based on the discussion, it appears that the change proposal can be viewed as ādeliberate intimidationā, which is explicitly specified as unacceptable behavior by Code of Conduct :: Fedora Docs
1 Like
Thank you Emily for that list. I took it and did the following:
$ cat > zzz
$ head -n 3 zzz
/usr/lib32/gconv/gconv-modules.cache
/usr/lib32/ld-linux.so.2
/usr/lib32/libblkid.so.1.1.0
$ sed -i 's/lib32/lib/; s/.so.*/.so/;' zzz
$ head -n 3 zzz
/usr/lib/gconv/gconv-modules.cache
/usr/lib/ld-linux.so
/usr/lib/libblkid.so
/usr/lib/libbrotlicommon.so
$ for i in `cat zzz`; do
> dnf repoquery --whatprovides=${i}
> done > zzz2
This gave me a list of packages for each requires which needed some āeditingā to remove duplicates. I also needed to edit out all the -devel packages because my sed made things look for those instead of real lib
Found on Fedora
NetworkManager-libnm-1:1.52.0-1.fc42.i686
brotli-0:1.1.0-6.fc42.i686
bzip2-0:1.0.8-20.fc42.i686
dbus-1:1.16.0-3.fc42.i686
elfutils-libelf-0:0.193-2.fc42.i686
expat-0:2.7.1-1.fc42.i686
fontconfig-0:2.16.0-2.fc42.i686
freetype-0:2.13.3-2.fc42.i686
glib2-0:2.84.2-1.fc42.i686
glibc-0:2.41-8.fc42.i686
harfbuzz-0:10.4.0-1.fc42.i686
libX11-0:1.8.11-1.fc42.i686
libXScrnSaver-0:1.2.4-5.fc42.i686
libXau-0:1.0.12-2.fc42.i686
libXdmcp-0:1.1.5-3.fc42.i686
libXext-0:1.3.6-3.fc42.i686
libXfixes-0:6.0.1-5.fc42.i686
libXinerama-0:1.1.5-8.fc42.i686
libXxf86vm-0:1.1.6-2.fc42.i686
libblkid-0:2.40.4-7.fc42.i686
libcap-0:2.73-2.fc42.i686
libdrm-0:2.4.124-2.fc42.i686
libdrm-0:2.4.125-1.fc42.i686
libffi-0:3.4.6-5.fc42.i686
libglvnd-1:1.7.0-7.fc42.i686
libicu-0:76.1-4.fc42.i686
libmount-0:2.40.4-7.fc42.i686
libnsl2-0:2.0.1-3.fc42.i686
libpciaccess-0:0.16-15.fc42.i686
libpng-2:1.6.44-2.fc42.i686
libuuid-0:2.40.4-7.fc42.i686
libva-0:2.22.0-4.fc42.i686
libxcb-0:1.17.0-5.fc42.i686
libxml2-0:2.12.10-1.fc42.i686
libxshmfence-0:1.3.2-6.fc42.i686
libzstd-0:1.5.7-1.fc42.i686
llvm-0:20.1.7-1.fc42.i686
nspr-0:4.36.0-9.fc42.i686
nss-0:3.112.0-1.fc42.i686
nss-util-0:3.112.0-1.fc42.i686
pcre2-0:10.45-1.fc42.i686
pipewire-0:1.4.6-1.fc42.i686
rpc2-0:2.37-1.fc42.i686
spirv-tools-libs-0:2025.2-2.fc42.i686
systemd-0:257.6-1.fc42.i686
xz-1:5.8.1-2.fc42.i686
zlib-ng-compat-0:2.2.4-3.fc42.i686
I expect most of these are already in the list I posted earlier. So it would be ~50 primary packages and whatever larger amount of āsecondaryā packages needed to compile those .
1 Like
Is fedora going to provide the 32bit libs required for nvidia.
$ rpm -qR xorg-x11-drv-nvidia-libs-575.64-1.fc42.i686
egl-gbm(x86-32) >= 2:1.1.2
egl-wayland(x86-32) >= 1.1.15
egl-x11(x86-32)
ld-linux.so.2
ld-linux.so.2(GLIBC_2.3)
libX11.so.6
libXext.so.6
libc.so.6
libc.so.6(GCC_3.0)
libc.so.6(GLIBC_2.0)
libc.so.6(GLIBC_2.1)
libc.so.6(GLIBC_2.1.2)
libc.so.6(GLIBC_2.1.3)
libc.so.6(GLIBC_2.11)
libc.so.6(GLIBC_2.2)
libc.so.6(GLIBC_2.2.3)
libc.so.6(GLIBC_2.3)
libc.so.6(GLIBC_2.3.4)
libc.so.6(GLIBC_2.4)
libc.so.6(GLIBC_2.7)
libc.so.6(GLIBC_2.9)
libdl.so.2
libdl.so.2(GLIBC_2.0)
libdl.so.2(GLIBC_2.1)
libdl.so.2(GLIBC_2.3.3)
libglvnd-egl(x86-32) >= 0.2
libglvnd-gles(x86-32) >= 0.2
libglvnd-glx(x86-32) >= 0.2
libglvnd-opengl(x86-32) >= 0.2
libm.so.6
libm.so.6(GLIBC_2.0)
libm.so.6(GLIBC_2.1)
libm.so.6(GLIBC_2.2)
libnvidia-allocator.so.1
libnvidia-glcore.so.575.64
libnvidia-glsi.so.575.64
libnvidia-gpucomp.so.575.64
libnvidia-tls.so.575.64
libpthread.so.0
libpthread.so.0(GLIBC_2.0)
libpthread.so.0(GLIBC_2.1)
libpthread.so.0(GLIBC_2.2)
libpthread.so.0(GLIBC_2.3.2)
libpthread.so.0(GLIBC_2.3.3)
libpthread.so.0(GLIBC_2.4)
librt.so.1
librt.so.1(GLIBC_2.2)
libvdpau(x86-32) >= 0.5
mesa-libEGL(x86-32)
mesa-libGL(x86-32)
mesa-libGLES(x86-32)
rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(FileDigests) <= 4.6.0-1
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rpmlib(PayloadIsZstd) <= 5.4.18-1
vulkan-loader(x86-32)
I dropped the nvidia 32bit libs for RHEL due to missing 32bit packages.
I imagine some of the dependencies are for specific runtimes or the steamworks API. Maybe @kylegospo will know?
Given feedback in this thread (and to a lesser extent, also on the mailing list) I have decided to withdraw this proposal.
-
It is clear that the Fedora 44 target for this Change was too early. To some degree, I expected this to be the case, and was prepared to move the proposed implementation of the Change to a later release. Fedora 44 was just the earliest āreasonableā target. However, I think this also shows an inherent conflict in the current Changes process - if a big Change (like this one) is submitted quite early (out of caution!), that also front-loads the discussion and decision process instead of giving things more time. For example, I donāt think the discussion would have been meaningfully different if the targeted release had been Fedora 46 instead of 44 - which is one of the reasons why I decided to withdraw the change instead of just re-targeting it at a later Fedora release.
-
I donāt think the problem that was attempted to be addressed with this proposal will go away. With more and more projects dropping official support for building / running their software on 32-bit architectures, itās just going to get worse over the next few years. Dealing with widely used software falling out from under our feet wonāt be fun. To some degree, always pushing the latest and greatest
software in Fedora is also working against us here - if we just stuck with foo 1.0 LTS for 10 years, we just wouldnāt need to care that foo 3.0 dropped support for running on 32-bit systems ā¦ -
I am disappointed in some of the reactions this
proposal has received, with some people apparently reading it in the most uncharitable way. It was a proposal that tried to address technical problems package maintainers and release engineering is facing, not some conspiracy to break the āgaming use caseā. That said, I was expecting a lot of feedback feedback on this one, but not hundreds of people shouting "DONāT DO THIS WHY DONāT YOU CARE ABOUT YOUR USERS I WILL SWITCH DISTROS IMMEDIATELY levels of feedback (though to some degree, I also blame clickbait ātech pressā or YouTubers for that ā¦)
I am now looking forward to seeing actual (and actionable) counter-proposals.
ā Fabio
36 Likes
@slaanesh Can you confirm the requirements for steam?
Itāll need to as well, thanks.
Could you share the list of games that you tried?
For completeness, thereās multiple different versions of the Linux runtime. We would need to make sure that the games you picked are indeed 32-bit and that they cover the three different Linux runtime versions that are bundled into Steam.
There are also a vast number of different versions of proton so 32-bit Windows game still need testing since Valve does not appear to be interested in WoW64 as a default.
This would be a very good first activity for the proposed gaming SIG.
Lastly as others have pointed out this only covers games being run through s
Steam. This is still harming 32-bit games that donāt come from Steam or go through tools Valve built like Proton (but whether Fedora wants to bother with that is a question in of itself).
One such source of titles like that is feral interactive who did the ports of games such as tomb raider and created the gamemode performance optimizer for Linux (not to be confused with steam game mode session).
2 Likes
As this Change has been withdrawn, the purpose of this thread has run its course, so Iām closing this thread.
18 Likes