ValveSoftware
system installed libstdc++ and steam-runtime's one coexistence
I'm trying to deal with a problem when the game strictly needs to use libstdc++ from the steam-runtime as it's updated to GLIBCXX_3_4_20 while the one installed in the system it's slightly older (3.4.19) on some versions of ubuntu. I reckon the problem is that the on start the binary picks up the system lib instead of the one from the chroot as they share the same path and somehow the system ones gets picked up. If I move away the system one the game picks up the correct one from the steam-runtimes and it works fine.
/home/user/.local/share/Steam/ubuntu12_32/steam-runtime/i386/usr/lib/i386-linux-gnu/libstdc++.so.6 /usr/lib/i386-linux-gnu/libstdc++.so.6
Because the system one has a wrong version the game doesn't start. I'm wondering if it's possible skip the system lib and just fallback on the one contained in the chroot. I understand it's not an 'issue' however I reckon other people might have had the same problem in the past.
Hello @daxliar, when dealing with steam as opposed to the steam runtime by itself, by default steam.sh compares the steam runtime libraries against the system libraries and pins the steam runtime variant of any libraries older than the steam runtime in .../steam-runtime/pinned_libs_32 and .../steam-runtime/pinned_libs_64. The default order libraries are resolved in is pinned_libs_*, system libraries, steam-runtime, then ld.so.conf.
This can be simplified to the steam runtime followed by ld.so.conf by running steam with STEAM_RUNTIME_PREFER_HOST_LIBRARIES=0 steam.
Can you check the pinned_libs_32 folder and see if libstdc++ is getting picked as it's supposed to? If it's not there, please close steam, move pinned_libs_* out of the way, and restart steam to regenerate those folders.
Hello @kisak-valve thank you, very helpful I've realized some Ubuntu version like 14.04 and older don't ship with 'realpath' installed by default so steam.sh line 431 fails and the pinned folders aren't created. After installing realpath via apt-get on this Ubuntu 14.04 solved the issue. I've checked the manifest of 14.04 and it isn't installed by default. Thank you for your help!
libgcc ABI and libstdc++ ABI is a nightmare. I did work around ALL those problems with a custom gnu/linux distro which has the decency to use the gcc linking flags -static-libgcc -static-libstdc++. Unfortunately, I found a bug in mesa related to libtool which compiles the dri drivers with the shared version libsdc++ and libgcc ignoring the previous gcc link flags. Only libgcc_s is required by the glibc for pthread_cancel (and it should not)
I have 2 GCCs installed on Gentoo.
$ cat /etc/ld.so.conf.d/05gcc-x86_64-pc-linux-gnu.conf
/usr/lib/gcc/x86_64-pc-linux-gnu/6.4.0/32
/usr/lib/gcc/x86_64-pc-linux-gnu/6.4.0
/usr/lib/gcc/x86_64-pc-linux-gnu/4.7.4/32
/usr/lib/gcc/x86_64-pc-linux-gnu/4.7.4
steam.sh found the old one, and chose to pin to the "new" one:
Found newer runtime version for 32-bit libstdc++.so.6. Host: 6.0.17 Runtime: 6.0.21
Found newer runtime version for 64-bit libstdc++.so.6. Host: 6.0.17 Runtime: 6.0.21
$ cat ~/.local/share/Steam/ubuntu12_32/steam-runtime/pinned_libs_64/system_libstdc++.so.6
/usr/lib/gcc/x86_64-pc-linux-gnu/4.7.4/libstdc++.so.6
/usr/lib64/gcc/x86_64-pc-linux-gnu/4.7.4/libstdc++.so.6.0.17
This results in errors:
libGL: dlopen /usr/lib64/dri/nouveau_dri.so failed (/home/user/.local/share/Steam/ubuntu12_32/steam-runtime/pinned_libs_64/libstdc++.so.6: version `GLIBCXX_3.4.22' not found (required by /usr/lib/llvm/5/lib64/libLLVMSupport.so.5))
Removing the pinned libstdc++.so.6 to let steam use the actual new host library fixes this somewhat.
@DarthGandalf sounds really suspicious how newer library would have less symbols than the old one like in your output...
@nanonyme no... Old library has less symbols. Steam used old library instead of new library, and therefore didn't find the needed symbol.
I guess I wasn't clear in my description. There are 3 versions of libstdc++:
- 6.0.17 in my system gcc 4.7.4
- 6.0.24 in my system gcc 7.3.0 (I don't remember which version it was at the time of posting, but the exact number doesn't matter - only their relative order matters)
- 6.0.21 shipped with steam
Steam found that I have 6.0.17, and pinned to 6.0.21, instead of using my 6.0.24. Using the latest one (6.0.24) would be the correct thing to do. The problem is that steam stopped the search when found my 6.0.17, and didn't consider the possibility of me having several libstdc++ versions installed.
Hm, those both host libraries listed when Steam calls ldconfig to get the system libraries for pinning? If they're not, sounds like a distro issue. If they are, sounds like Steam just doesn't currently have the logic of figuring out the newest host library if multiple versions with same soname are present.
Yes, all versions are listed there.
$ ldconfig -p|grep stdc
libstdc++.so.6 (libc6,x86-64) => /usr/lib/gcc/x86_64-pc-linux-gnu/7.3.0/libstdc++.so.6
libstdc++.so.6 (libc6,x86-64) => /usr/lib/gcc/x86_64-pc-linux-gnu/6.4.0/libstdc++.so.6
libstdc++.so.6 (libc6) => /usr/lib/gcc/x86_64-pc-linux-gnu/7.3.0/32/libstdc++.so.6
libstdc++.so.6 (libc6) => /usr/lib/gcc/x86_64-pc-linux-gnu/6.4.0/32/libstdc++.so.6
libstdc++.so (libc6,x86-64) => /usr/lib/gcc/x86_64-pc-linux-gnu/7.3.0/libstdc++.so
libstdc++.so (libc6,x86-64) => /usr/lib/gcc/x86_64-pc-linux-gnu/6.4.0/libstdc++.so
libstdc++.so (libc6) => /usr/lib/gcc/x86_64-pc-linux-gnu/7.3.0/32/libstdc++.so
libstdc++.so (libc6) => /usr/lib/gcc/x86_64-pc-linux-gnu/6.4.0/32/libstdc++.so
6.4.0 has libstdc++ 6.0.22, btw, which is still newer than 6.0.21
libstdc++ should be statically linked, same than with libgcc. Either the distro or steam runtime has to do it.
Since I use my own distro and not those mainstream distros, libgcc and libstdc++ are statically linked in my 3D driver stack (mesa), I don't have pbs with that anymore.
The real culprits are gcc ppl with their shared libstdc++ and libgcc, not valve, not distro integrators. c++ ABI is pure insanity anyway.