"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.
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).
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.
@Shotweb grep is helpful for this:
# filters out lines containing exactly "text" from inputfile and writes to outputfile
grep -vxFe "text" inputfile > outputfile
"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.
Nothing extracted yet.
Your system information
Please describe your issue in as much detail as possible:
Steam adds both the 32bit and 64bit version of
gameoverlayrenderer.soto theLD_PRELOADpath which causes lots of noisy error messages in steam's log output such as: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
$LIBin theLD_PRELOADpath, it's possible forld.soto appropriately load the 32 or 64 bit version of a dynamic library based on the executable that is loaded. For example:From running this example, we can see that both 32 and 64 bit versions of wine get the correct version of libc. Note
$LIBneeds to be escaped with single quotes, or otherwise the shell will try to expand it as a variable.The only complication is that
$LIBcan expand to different values depending on the Linux distro that is run. For example:On Debian/Ubuntu 64 bit:
$LIBfor 64 bit ELF -> lib/x86_64-linux-gnu$LIBfor 32 bit ELF -> lib/i386-linux-gnuWhile Arch 64 bit:
$LIBfor 32 bit ELF -> lib32$LIBfor 64 bit ELF -> libSo for this workaround, steam would provide symlinks to
ubuntu12_32/gameoverlayrenderer.soandubuntu12_64/gameoverlayrenderer.sothat incorporate the appropriate values of$LIBfor the given system. I don't know if there is an easy way to check what values$LIBexpands to inld.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:
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.