Wrong 32bit library path in RPM based distributions

[VortexAcherontic]

Hey there initially I thought this is a pressure vessel issue like described in the pinned issue #369 but I found out that with the current SoldierRuntime (0.20201124.0) and Proton 5.13-3 MangoHud works fine on games using Proton + DXVK if they are 64bit games.

Also I assume this is not a pressure vessel or Steam Runtime issue since I can reproduce the same behavior by using native games or games running via Lutris + Wine

Unfortunately I have no native 32bit Vulkan game available so this is the only case which remains untested

I also checked the MangoHud installation and the 32bit sos seems to be there I prepared some logs which hopefully help you narrowing down this issue. Or I am just missing something on my end.

• ❌ Gothic 3 - Wine - DXVK - 32bit - Log
• ✔ The Witcher 3 - Wine - DXVK - 64bit - Log
• ❌ Darksburg - Proton - OpenGL - 64bit - Proton Log - Tried --dlsym as well to no avail here
• ✔ Darksburg - Proton - DXVK - 64bit - Proton Log
• ❌ Kao: The Kangaroo: Round 2 - Proton - OpenGL - 32bit - Log - Tried --dlsym here too to no avail Also this one worked with an older version of Proton and MangoHud
• ❌ Fitzquake - Native - OpenGL - 32bit - Log
• ✔ GLXgears - Native - OpenGL - 64bit - Log
• ✔ VKCube - Native - Vulkan - 64bit - Log

Specs:
MangoHud: 0.6.1
OS: openSUSE Tumbleweed
Kernel: 5.9.12
GPU: GTX 1080
Driver: 455.46.1

[Leopard1907]

That is still a runtime issue. 32 bit layers doesn't work with runtime.

https://gitlab.steamos.cloud/steamrt/steam-runtime-tools/-/issues/39

32 bit games on Lutris were working for me last time i checked. I can try later again.

Edit: 32 bit game - via Lutris EGS - works

[flightlessmango]

I would say this still falls under #369

[VortexAcherontic]

@flightlessmango This would not explain the native games who did not worked as well as any game running via Lutris without Pressure Vessel.
But it may very well be the case that I just missed something on my end so I think for now it is the better decision to close this issue until I can verify it is indeed an issue and not me just forget about something 😄

@Leopard1907 Which version of wine did you use? I had lutris-5.21 running in my tests in which the Hud did not worked.

[Leopard1907]

Lutris 5.21 is the build i used.

[flightlessmango]

Try using something like glxspheres32, comes with the 32bit virtualgl package on arch

[flightlessmango]

Or try this vkcube32

[VortexAcherontic]

I guess something is off with my installation but I can not narrow down what it is:

mangohud ./vkcube32 
ERROR: ld.so: object '/usr/lib/mangohud/$LIB/libMangoHud.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS64): ignored.
failed to initialize wayland, falling back to xcb
2 physical devices
vendor id 10de, device name GeForce GTX 1080

[flightlessmango]

Are you using the release package?

[VortexAcherontic]

Yes I do. Downloaded the 0.6.1 release package from here to avoid miss packaging of my distros package maintianer (they entirely missed out lib32 there ...). And run the mangohud installer script.

[DadSchoorse]

The issue probably is that the mangohud install script uses /lib for 64bit, but on opensuse/fedora it's for 32bit (and /lib64 for 64bit).

[VortexAcherontic]

It was working fine with any prior release until recently but also Manghud has symlinks for this to address this:

/usr/lib/mangohud> LC_ALL=C ll
total 24
lrwxrwxrwx 1 root root   5 Dec 10 00:30 i386-linux-gnu -> lib32
lrwxrwxrwx 1 root root   5 Dec 10 00:30 i686 -> lib32
lrwxrwxrwx 1 root root   5 Dec 10 00:30 i686-linux-gnu -> lib32
drwxr-xr-x 1 root root 184 Dec 10 00:30 lib
drwxr-xr-x 1 root root  68 Dec 10 00:30 lib32
lrwxrwxrwx 1 root root   3 Dec 10 00:30 lib64 -> lib
drwxr-xr-x 1 root root  20 Dec 10 00:30 tls
lrwxrwxrwx 1 root root   3 Dec 10 00:30 x86_64 -> lib
lrwxrwxrwx 1 root root   3 Dec 10 00:30 x86_64-linux-gnu -> lib

[DadSchoorse]

Yes, and those symlinks are wrong on rpm based distros. lib should be a symlink to lib32, not lib64.

[VortexAcherontic]

You're right sir! That did the trick! Thank you.

I moved the folder in /usr/lib/mangohud to be as follows

lib for 32bit
lib64 for 64bit

and now things work as expected.

@flightlessmango fyi.

[AngryPenguinPL]

Yes, same issue on OpenMandriva.
Installed both x86_64 and i686 packages.
x86_64 provides /usr/lib64/mangohud/ and contains both libMangoHud.so and libMangoHud.dlsym.so
while i686 provides /usr/lib/mangohud/ and contains both libMangoHud.so and libMangoHud.dlsym.so
but overlay on 32-bit app still won\t work

edit:
Anyway it still should works. Look at /usr/bin/mangohud

# Preload using the plain filesnames of the libs, the dynamic linker will
# figure out whether the 32 or 64 bit version should be used, and will search
# for it in the correct directory
LD_PRELOAD="${LD_PRELOAD}:${MANGOHUD_LIB_NAME}"
LD_LIBRARY_PATH="${LD_LIBRARY_PATH}:/usr/\$LIB/mangohud/"

This mean, that loader should use %LIB prefix and detectd if this is a 32 or 64 bit stuff.

[dagolinuxoid]

Rather than creating a new issue I decided to put my question here:
I'm trying to get mangohud overlay to work on Guilty Gear AC + R game which I'm launching via wine but it doesn't work (I do have working overlay when I play dota 2 through steam though) . Elementary OS Hera, there is the result:

I tried to create those wine-explorer and other not founded files with a content of Mangohud.cfg but it didn't help.

[VortexAcherontic]

The configs are irrelevant and just extra places MangoHud looks for config files in case you want different HUD elements for different applications here and also this seems not to belong to this issue.
You can however instead try:

mangohud --dlsym wine GGXXACPR_Win.exe

[dagolinuxoid]

--dlsym flag did the trick thx vortex

[Hasshu]

Any updates on this? Fedora and openSUSE aren't exactly some random hobby distros.

[VortexAcherontic]

In the openSUSE repos this issue is currently worked around by some build time modifications: https://build.opensuse.org/package/show/games:tools/mangohud
Maybe you can talk to the fedora maintainers and see if they could make use of it as well so some does not need to wait for the devs to catch up.

[Hasshu]

@VortexAcherontic According to this, the 32-bit package should install "automagically" on Fedora these days... yet I just found out that it didn't happen. Maybe that doesn't work when MangoHud is among the first packages to be installed on a fresh system. Or maybe the maintainer is a Muggle.

Either way, it's always a good idea to fix such issues upstream.

[Fatmice]

For fedora, I needed to fix all of the symlinks and directory names into these

tree -s /usr/lib/mangohud
/usr/lib/mangohud
├── [          3]  i386-linux-gnu -> lib
├── [          3]  i686 -> lib
├── [          3]  i686-linux-gnu -> lib
├── [       4096]  lib
│   ├── [      21044]  libMangoHud_dlsym.so
│   └── [    2104808]  libMangoHud.so
├── [       4096]  lib64
│   ├── [          6]  i386-linux-gnu -> ../lib
│   ├── [          1]  i686-linux-gnu -> .
│   ├── [          6]  lib32 -> ../lib
│   ├── [      22464]  libMangoHud_dlsym.so
│   ├── [    1983192]  libMangoHud.so
│   ├── [          6]  tls -> ../tls
│   ├── [          1]  x86_64 -> .
│   └── [          1]  x86_64-linux-gnu -> .
├── [       4096]  tls
│   ├── [          6]  i686 -> ../lib
│   └── [          9]  x86_64 -> ../lib64/
├── [          5]  x86_64 -> lib64
└── [          5]  x86_64-linux-gnu -> lib64

For comparison, these are made by the installation script

tree -s /usr/lib/mangohud/
/usr/lib/mangohud/
├── [          5]  i386-linux-gnu -> lib32
├── [          5]  i686 -> lib32
├── [          5]  i686-linux-gnu -> lib32
├── [       4096]  lib
│   ├── [          8]  i386-linux-gnu -> ../lib32
│   ├── [          1]  i686-linux-gnu -> .
│   ├── [          8]  lib32 -> ../lib32
│   ├── [      22464]  libMangoHud_dlsym.so
│   ├── [    1983192]  libMangoHud.so
│   ├── [          6]  tls -> ../tls
│   ├── [          1]  x86_64 -> .
│   └── [          1]  x86_64-linux-gnu -> .
├── [       4096]  lib32
│   ├── [      21044]  libMangoHud_dlsym.so
│   └── [    2104808]  libMangoHud.so
├── [          3]  lib64 -> lib
├── [       4096]  tls
│   ├── [          8]  i686 -> ../lib32
│   └── [          6]  x86_64 -> ../lib
├── [          3]  x86_64 -> lib
└── [          3]  x86_64-linux-gnu -> lib

Fedora expects lib to be for 32-bit libraries, and lib64 to be for 64-bit libraries. This trip up with the other convention of lib32 and lib64 has caused countless headaches since time immemorioal

[AlexFolland]

FYI, from my testing of this today and yesterday, mangohud works perfectly fine with 32-bit games in wine on Manjaro unstable using the lib32-mangohud-git AUR package. I used mangohud --dlsym wine '/home/alex/.wine/drive_c/games/fix it felix jr/FIFJ.exe' and that showed the mangohud overlay correctly here.

Therefore, I believe this issue ticket as it is currently titled ("MangoHud does not work in 32bit games Proton/Wine/Native DXVK/OpenGL" as of writing this comment) is not necessarily entirely valid, as there are situations where it works as expected with 32-bit software running in wine.

Is the issue resolved in Fedora and OpenSUSE yet? If not, does that really reflect poorly on the mangohud project? If not, can this ticket be closed? I ask because this ticket's contents misled me when I was trying to get mangohud to work in a 32-bit game running in wine on Manjaro yesterday and all I needed to do was install the lib32-mangohud-git AUR package and not do some surgical directory tree and symlink manipulation.