Loading both 32 and 64 bit versions of gameoverlayrenderer.so generates lots of error messages.

[momumi]

Your system information

• Steam client version (build number or date): 2019/11/20
• Distribution (e.g. Ubuntu): Arch
• Opted into Steam client beta?: Yes
• Have you checked for system updates?: Yes

Please describe your issue in as much detail as possible:

Steam adds both the 32bit and 64bit version of gameoverlayrenderer.so to the LD_PRELOAD path which causes lots of noisy error messages in steam's log output such as:

ERROR: ld.so: object '/home/user/.local/Steam/ubuntu12_32/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored.

While this doesn't causes any issues with games, it can be annoying when debugging games that aren't working, and it can fool inexperienced users who may think something is wrong when they look at the log output. Instead, these error messages should not be generated.

Potential fix

Using $LIB in the LD_PRELOAD path, it's possible for ld.so to appropriately load the 32 or 64 bit version of a dynamic library based on the executable that is loaded. For example:

LD_PRELOAD='/usr/$LIB/libc.so.6' ldd /usr/bin/wine
LD_PRELOAD='/usr/$LIB/libc.so.6' ldd /usr/bin/wine64

From running this example, we can see that both 32 and 64 bit versions of wine get the correct version of libc. Note $LIB needs to be escaped with single quotes, or otherwise the shell will try to expand it as a variable.

The only complication is that $LIB can expand to different values depending on the Linux distro that is run. For example:

On Debian/Ubuntu 64 bit:

• $LIB for 64 bit ELF -> lib/x86_64-linux-gnu
• $LIB for 32 bit ELF -> lib/i386-linux-gnu

While Arch 64 bit:

• $LIB for 32 bit ELF -> lib32
• $LIB for 64 bit ELF -> lib

So for this workaround, steam would provide symlinks to ubuntu12_32/gameoverlayrenderer.so and ubuntu12_64/gameoverlayrenderer.so that incorporate the appropriate values of $LIB for the given system. I don't know if there is an easy way to check what values $LIB expands to in ld.so, so one possible solution might be to provide them as environment variables and fallback to the old behavior when not given.

Steps for reproducing this issue:

1. Launch any game on steam.
2. Read steam's log output and find several error messages like ERROR: ld.so: object '/home/user/.local/Steam/ubuntu12_32/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored. This is particularly bad in Proton games which spawn many processes.

[ghost]

"can fool inexperienced users who may think something is wrong when they look at the log output"

Unfortunately, anything can be in there that can fool anyone other than the actual devs. This is but one log entry that can first time someone looks to understand the logs. But its found in logs for games that run fine so a comparison is all the is needed to know if its fine or not.

[smcv]

The only complication is that $LIB can expand to different values depending on the Linux distro that is run.

That's a pretty big complication for a piece of software that wants to be portable to multiple distros. For a long time I thought that the only major implementations were Red-Hat-style multilib (lib and lib64) and Debian-style multiarch (lib/*-linux-gnu), but Arch-style multilib is not the same as Red Hat (lib32 and lib), I recently discovered that Exherbo has an installation layout that is a lot like Debian multiarch but the other way round, based on traditional cross-compiler layouts (*-pc-linux-gnu/lib), and I'm sure there are other schemes in use.

Also, on Debian/Ubuntu it depends on the release, not just the distribution. There are some older releases (definitely Ubuntu 12.04, possibly others) where the libraries are in lib/*-linux-gnu but $LIB still expands to lib (for both ABIs).

It would probably be more reliable to use $PLATFORM. For the x86_64 ABI, $PLATFORM is x86_64; for the IA32 (i386) ABI, $PLATFORM is usually i686 these days, but might be i586, i486 or i386 in older distributions (which is few enough variations that it's reasonable to pick one of them to be a real directory, and use symlinks to provide the rest).

[Shotweb]

I would really wish the error message could be done away with. I'm trying to debug Steam crashing but I can barely manage to see the error message because this one is being spammed several times a second.

[kupiakos]

@Shotweb grep is helpful for this:

# filters out lines containing exactly "text" from inputfile and writes to outputfile
grep -vxFe "text" inputfile > outputfile

[DonKatsu]

"Several" messages is an understatement in some cases. I was checking my journal for something else and was hit with walls of "cannot be preloaded" messages. An example from a single game session.