[0.6.9] Failing to launch MangoHud in Steam - error while loading shared libraries: libspdlog.so.1.11

[gmbeard]

I'm in the process of updating my voidlinux XBPS package of MangoHud to version 0.6.9. A change in this version causes a failure to launch Steam games when MangoHud is used as a launch option. In contrast, version 0.6.8 has been working fine.

The error from the Steam log is:

error while loading shared libraries: libspdlog.so.1.11: cannot open shared object file: No such file or directory

If I revert f47f777 then everything appears to work fine. This suggests there are some oddities around library paths.

What I find strange is the strace output appears to show the process failing to find libspdlog.so when the file absolutely exists at /usr/lib32/libspdlog.so.1.11...

Extract from strace

27395 openat(AT_FDCWD, "/home/gmbeard/.local/share/Steam/ubuntu12_64/video/libspdlog.so.1.11", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 ENOENT (No such file or directory)
27395 openat(AT_FDCWD, "/home/gmbeard/.local/share/Steam/ubuntu12_32/video/libspdlog.so.1.11", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 ENOENT (No such file or directory)
27395 openat(AT_FDCWD, "/home/gmbeard/.local/share/Steam/steamapps/common/Proton - Experimental/files/lib64/libspdlog.so.1.11", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 ENOENT (No such file or directory)
27395 openat(AT_FDCWD, "/home/gmbeard/.local/share/Steam/steamapps/common/Proton - Experimental/files/lib/libspdlog.so.1.11", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 ENOENT (No such file or directory)
27395 openat(AT_FDCWD, "/usr/lib/pressure-vessel/overrides/lib/x86_64-linux-gnu/aliases/libspdlog.so.1.11", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 ENOENT (No such file or directory)
27395 openat(AT_FDCWD, "/usr/lib/pressure-vessel/overrides/lib/i386-linux-gnu/aliases/libspdlog.so.1.11", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 ENOENT (No such file or directory)
27395 openat(AT_FDCWD, "/usr/lib32/tls/i686/sse2/libspdlog.so.1.11", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 ENOENT (No such file or directory)
27395 statx(AT_FDCWD, "/usr/lib32/tls/i686/sse2", AT_STATX_SYNC_AS_STAT|AT_NO_AUTOMOUNT, STATX_BASIC_STATS, 0xff8f1708) = -1 ENOENT (No such file or directory)
27395 openat(AT_FDCWD, "/usr/lib32/tls/i686/libspdlog.so.1.11", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 ENOENT (No such file or directory)
27395 statx(AT_FDCWD, "/usr/lib32/tls/i686", AT_STATX_SYNC_AS_STAT|AT_NO_AUTOMOUNT, STATX_BASIC_STATS, 0xff8f1708) = -1 ENOENT (No such file or directory)
27395 openat(AT_FDCWD, "/usr/lib32/tls/sse2/libspdlog.so.1.11", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 ENOENT (No such file or directory)
27395 statx(AT_FDCWD, "/usr/lib32/tls/sse2", AT_STATX_SYNC_AS_STAT|AT_NO_AUTOMOUNT, STATX_BASIC_STATS, 0xff8f1708) = -1 ENOENT (No such file or directory)
27395 openat(AT_FDCWD, "/usr/lib32/tls/libspdlog.so.1.11", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 ENOENT (No such file or directory)
27395 statx(AT_FDCWD, "/usr/lib32/tls", AT_STATX_SYNC_AS_STAT|AT_NO_AUTOMOUNT, STATX_BASIC_STATS, 0xff8f1708) = -1 ENOENT (No such file or directory)
27395 openat(AT_FDCWD, "/usr/lib32/i686/sse2/libspdlog.so.1.11", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 ENOENT (No such file or directory)
27395 statx(AT_FDCWD, "/usr/lib32/i686/sse2", AT_STATX_SYNC_AS_STAT|AT_NO_AUTOMOUNT, STATX_BASIC_STATS, 0xff8f1708) = -1 ENOENT (No such file or directory)
27395 openat(AT_FDCWD, "/usr/lib32/i686/libspdlog.so.1.11", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 ENOENT (No such file or directory)
27395 statx(AT_FDCWD, "/usr/lib32/i686", AT_STATX_SYNC_AS_STAT|AT_NO_AUTOMOUNT, STATX_BASIC_STATS, 0xff8f1708) = -1 ENOENT (No such file or directory)
27395 openat(AT_FDCWD, "/usr/lib32/sse2/libspdlog.so.1.11", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 ENOENT (No such file or directory)
27395 statx(AT_FDCWD, "/usr/lib32/sse2", AT_STATX_SYNC_AS_STAT|AT_NO_AUTOMOUNT, STATX_BASIC_STATS, 0xff8f1708) = -1 ENOENT (No such file or directory)
27395 openat(AT_FDCWD, "/usr/lib32/libspdlog.so.1.11", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 ENOENT (No such file or directory)
27395 statx(AT_FDCWD, "/usr/lib32", AT_STATX_SYNC_AS_STAT|AT_NO_AUTOMOUNT, STATX_BASIC_STATS, {stx_mask=STATX_BASIC_STATS|STATX_MNT_ID, stx_attributes=0, stx_mode=S_IFDIR|0755, stx_size=4096, ...}) = 0
27395 writev(2, [{iov_base="/home/gmbeard/.local/share/Steam/st"..., iov_len=83}, {iov_base=": ", iov_len=2}, {iov_base="error while loading shared libra"..., iov_len=36}, {iov_base=": ", iov_len=2}, {iov_base="libspdlog.so.1.11", iov_len=17}, {iov_base=": ", iov_len=2}, {iov_base="cannot open shared object file", iov_len=30}, {iov_base=": ", iov_len=2}, {iov_base="No such file or directory", iov_len=25}, {iov_base="\n", iov_len=1}], 10) = 200

This problem exists for both the 64bit and the 32bit packages.

Can anyone help explain what might be going on, here?

Tested with:

• Steam / Proton ❌
• glxgears ✔️
• vkcube ✔️

---

Here are some details about the XBPS package itself...

XBPS Package change

--- a/srcpkgs/MangoHud-nvidia/template
+++ b/srcpkgs/MangoHud-nvidia/template
@@ -1,23 +1,21 @@
 # Template file for 'MangoHud-nvidia'
 pkgname=MangoHud-nvidia
-version=0.6.8
+version=0.6.9
 revision=1
 build_style=meson
-configure_args="-Duse_system_vulkan=enabled -Dwith_xnvctrl=disabled
- -Dwith_nvml=enabled -Duse_system_spdlog=enabled"
+configure_args="-Dwith_xnvctrl=disabled -Dwith_nvml=enabled -Duse_system_spdlog=enabled"
 hostmakedepends="Vulkan-Headers python3-Mako glslang pkg-config"
-makedepends="libglvnd-devel dbus-devel vulkan-loader Vulkan-Headers
- spdlog"
+makedepends="libglvnd-devel dbus-devel vulkan-loader Vulkan-Headers spdlog"
 short_desc="Vulkan and OpenGL overlay for monitoring FPS, temperatures and more"
 maintainer="gmbeard <gmbeard@googlemail.com>"
 license="MIT,custom:NVIDIA"
 homepage="https://github.com/flightlessmango/MangoHud"
 distfiles="https://github.com/flightlessmango/MangoHud/releases/download/v${version}/MangoHud-v${version}-Source.tar.xz"
-checksum=9c64ccab1a72ba1dc61cb88d2fbcce1d343fc6b6cdf22c2cc2859bfb2da66fd4
+checksum=a6e59ad810a30cd0a6a62ac5a7b5d8a10abab48eb1312e084ca7c81472d76573
 conflicts=MangoHud
 repository=nonfree
 
 post_patch() {
 	if [ "$XBPS_TARGET_LIBC" = "musl" ]; then
 		patch -Np0 -i ${FILESDIR}/musl.patch
 	fi

Package contents

64bit

/usr/bin/mangohud
/usr/lib/mangohud/libMangoHud.so
/usr/lib/mangohud/libMangoHud_dlsym.so
/usr/share/doc/mangohud/MangoHud.conf.example
/usr/share/icons/hicolor/scalable/apps/io.github.flightlessmango.mangohud.svg
/usr/share/licenses/MangoHud-nvidia/LICENSE
/usr/share/licenses/MangoHud-nvidia/LICENSE-NVIDIA
/usr/share/man/man1/mangohud.1
/usr/share/metainfo/io.github.flightlessmango.mangohud.metainfo.xml
/usr/share/vulkan/implicit_layer.d/MangoHud.x86_64.json

Additionally, for 32bit

/usr/lib32/mangohud/libMangoHud.so
/usr/lib32/mangohud/libMangoHud_dlsym.so

[flightlessmango]

I don't see how that commit would mess with this. Since this only happens with proton (?) I'm wondering if this can/should be fixed in the steam runtime

[gmbeard]

@flightlessmango It doesn't appear to be isolated to Steam/Proton - I get the same issue with Minecraft.

Using the official MC launcher, I use the following wrapper script to enable MangoHud (which, again, was working on 0.6.8, and works for 0.6.9 if I revert the commit)...

export MANGOHUD_DLSYM=1
mangohud $HOME/.minecraft/runtime/java-runtime-gamma/linux/java-runtime-gamma/bin/java "${@}"

It's entirely possible that this is a path/config/env issue on my machine, so I'll do some more investigating.

[evelikov]

@gmbeard I suggest reducing or deducing the offending component as to why it's failing on your end and not elsewhere. Is that due to the shared libspdlog, the extra changes (musl other?) in your packaging, other.

At a glance two bits stand out a) Vulkan-Headers should be removed like and b) the 32bit package is missing the icd json

[gmbeard]

Thank you for your suggestions, @evelikov

the 32bit package is missing the icd json

It turns out that this was precisely the problem. Unlike the pure 32bit package, the multi-lib (i.e. 32bit binary on 64bit host) XBPS package was only installing the 32bit libs and not the ICD file. I've fixed this now so that the multi-lib package also installs a 32bit ICD.

I can't really explain it but this must have worked in previous versions because of the $LIB variable in the ICD's path.

Thanks again. Much appreciated.