So I may not be the first person to bring this up but I really feel the need to do so as this could become a growing issue in the near future. It is straight forward. Steam often fails to load one particular libc module due to the way it targets architecture and linux branch. In my honest opinion, this problem may be the one thing that will hold llinux gaming the most.
Anyhow, the current steam package contained in the aur and in arch distros, the launcher was designed off of ubuntu 12.04 according to some of its installed libraries. It has segments that are meant for apt commands, which are not available on arch linux. That is relatively minor in context of the real issue.
I have seen several complaints about this but many users have run into an error saying that your system is missing a 32 libc.so.6. Any one who is paying close attention might realize that this is in fact, a typo pointing to a non existent module. It should be looking foi libc6.so in lib32, not libc.so.6 or i386, which was dropped from the linux kernel starting with 6.6. That factor may or may not be relevant.
What is relevant is the fact that the overall installer does not appear to have been updated in quite some time. If my deductions are correct, the only thing that needs to be modified is to make it target the right architecture x86-64 not amd64 and replace the parts that are for debian and not arch. Also, on a side note, there could be some driver problems since in some cases, arch stores their driver moduels in somewhat different locations than debian, which in some cases, can cause a package in .deb format to incorrectly read from a directory that does not exist on arch but does on debian. In fact, a lot of gpu bugs and video acceleration can be attributed to this discrepancy.
A further thing of note is the fact that steam has set things up where the .py fille that works to reference a script stored in /home/user/.local/steam to run the script that is supposed to find the proper kernel modules. Not sure if this is of any importance but considering that most modules are not owned by the home user, I wouldn’t be surprised if this introduces any sort of broken hardlinks.
So I would like to ask if there is any work planned to deal with these kinds of potential problems as i386 continues to lose support yet remains as a required dependency for the steam application.
Could you provide logs?
I can not reproduce this on my machine, neither with Steam Native nor runtime.
There’s a very small number of places mentioning libc.so.6 (and none for libc6.so) in the CachyOS repositories.
You probably already know this, but files inside $HOME/{.steam,.local/share/Steam} are created after running the Steam client. Maybe backup those directories, then re-run Steam. I’d start with Runtime first making sure that works before using Native.
Also check some items mentioned here: Steam Troubleshooting: Finding missing runtime libraries
I recommend filing a bug with the “Steam for Linux” project. With a preliminary search, I did not see anything currently open for Arch and “libc6.so” or “libc.so.6”.
Personally I was using Native first starting out with ArchLinux. Then switched to Runtime early this year after Valve changed symlink behavior in the runtimes and further containerizing the “browser” in the client.
You expect me to just wait until they supposedly get around to possibly fixing this? When they have over 2900 open cases under the issues tab? That is not very assuring, and I would rather be able to find out where this misbehavior is stemming from via the text files that steam runtime has installed. This kind of problem can usually be fixed pretty easily if you find which file is looking for the said module.
If I create an aliased module for libc.so.6 that is symbolically linked to libc6.so or libc6.so.6 in lib32, it should get it to stop complaining about the missing library. But there is one thing that has me apprehensive towards doing this. See, if I make a symlink to lib32 libc6.so.6, that might cause it to ignore libc6.so.6 in lib64 or the base /usr/lib.
The alternatives would be for me to find the line running the check and have it look for the correct module than the one that does not exist, or symlink the steam text file to the correct module. All of these solutions involve me having to modify things to target the right module at some point during the interaction of the involved files.