OpenGL fail "can't get dlopen()"

[CrimsonFork]

64 bit OpenGL games reliably fail almost immediately with

can't get dlopen()

as the only terminal output

Ubuntu 21.10, happens with the builds from the Ubuntu repository, latest stable and latest builds from GitHub all the like.

[reid-rigo]

I encountered this same issue, and upgrading from v0.6.5 to v0.6.6-1 solved it

[akien-mga]

I had the same issue too with v0.6.5, which is currently shown as the latest release:

@flightlessmango I suggest marking all releases as full releases, or all as "pre-release", but not a mix of both (unless v0.6.6-1 is really not meant to be used instead of v0.6.5 in a stable environment).

[johnblommers]

To reproduce easily (assume you installed the mesa-utils package:

mangohud glxgears
can't get dlopen()

By itself glxgears runs just fine.

But mangohud works fine with vkcube. This is on PopOS 21.10 which runs GNOME/Cosmic 404.0. And kernel 5.17.3. Mesa 21.3.5

[flightlessmango]

Since 0.6.7 is released this should not be an issue

[johnblommers]

Confirmed fixed in version 0.6.7 :-)
It also works after upgrading PopOS to 22.04.
Cool.

[biggestsonicfan]

Had to remove Mangohud from lutris ages ago because of this issue. Decided to give it another try because I'm seeing weird frame drops. Still have this issue.

[flightlessmango]

@cglmrfreeman If you scroll up you can see that it's been fixed, you're using an old version of mangohud.

[biggestsonicfan]

@cglmrfreeman If you scroll up you can see that it's been fixed, you're using an old version of mangohud.

I can see that, I can see the issue is closed, and I am using the latest version. I would not have commented after both seeing the issue closed and reading the comments below saying it was fixed.

The issue is persisting for me, unless it's somehow not related to OpenGL.

[flightlessmango]

Since it's been fixed, we're unable to reproduce it. So some information could be useful like: what version of mangohud exactly are you on, what games/apps have you tried with, what OS are you using etc.

[jackun]

@cglmrfreeman if you see only can't get dlopen(), you don't have latest version installed. Latest should print MANGOHUD: Can't get dlopen() but hopefully it's fixed for glibc >= 2.34. Musl is probably still...well.

[biggestsonicfan]

Well, I just tested mangohud glxgears and it ran. So it's an unrelated issue that's causing can't get dlopen() with mangohud via lutris.

[jackun]

Maybe there's somehow some other version installed somewhere and lutris picks it up.
LD_DEBUG=libs :P

[biggestsonicfan]

Maybe there's somehow some other version installed somewhere and lutris picks it up. LD_DEBUG=libs :P

Wow this log contains some straight up nonsense. What the heck is lutris even doing?! ow-mangohud-log.log

OS: openSUSE Tumbleweed 20220516
Kernel: x86_64 Linux 5.17.7-1-default
Lutris: lutris-0.5.10.1
mangohud (and 32 bit ver): 0.6.7~1-1.1

[jackun]

Should be fine, but if this gives you trouble then your 32bit MangoHud seems to be out of date.

[biggestsonicfan]

S  | Name                     | Type    | Version     | Arch   | Repository
---+--------------------------+---------+-------------+--------+--------------------------
i+ | mangohud                 | package | 0.6.7~1-1.1 | x86_64 | openSUSE:Tumbleweed
i+ | mangohud                 | package | 0.6.7~1-1.1 | x86_64 | openSUSE:Tumbleweed
i+ | mangohud                 | package | 0.6.7~1-1.1 | x86_64 | openSUSE:Tumbleweed
i+ | mangohud                 | package | 0.6.7~1-1.1 | x86_64 | openSUSE-Tumbleweed-Oss
v  | mangohud                 | package | 0.6.7~1-1.1 | i586   | openSUSE:Tumbleweed
v  | mangohud                 | package | 0.6.7~1-1.1 | i586   | openSUSE:Tumbleweed
v  | mangohud                 | package | 0.6.7~1-1.1 | i586   | openSUSE:Tumbleweed
v  | mangohud                 | package | 0.6.7~1-1.1 | i586   | openSUSE-Tumbleweed-Oss
i+ | mangohud-32bit           | package | 0.6.7~1-1.1 | x86_64 | openSUSE:Tumbleweed
i+ | mangohud-32bit           | package | 0.6.7~1-1.1 | x86_64 | openSUSE:Tumbleweed
i+ | mangohud-32bit           | package | 0.6.7~1-1.1 | x86_64 | openSUSE:Tumbleweed
i+ | mangohud-32bit           | package | 0.6.7~1-1.1 | x86_64 | openSUSE-Tumbleweed-Oss
   | mangohud-32bit-debuginfo | package | 0.6.7~1-1.1 | x86_64 | openSUSE-Tumbleweed-Debug
   | mangohud-debuginfo       | package | 0.6.7~1-1.1 | x86_64 | openSUSE-Tumbleweed-Debug
   | mangohud-debuginfo       | package | 0.6.7~1-1.1 | i586   | openSUSE-Tumbleweed-Debug
   | mangohud-debugsource     | package | 0.6.7~1-1.1 | x86_64 | openSUSE-Tumbleweed-Debug
   | mangohud-debugsource     | package | 0.6.7~1-1.1 | i586   | openSUSE-Tumbleweed-Debug

Is it?

[jackun]

Yeah, i think you have old release package installed. Nuke the rm -fr /usr/lib/mangohud and reinstall the packages, mangohud-32bit at least.

[biggestsonicfan]

That is like, really, really, really stupid that that worked 🤦. I had always assumed uninstalling and reinstalling packages would remove such data, but apparently not. Is there some documentation where it says this folder may need refreshing?

[jackun]

Random tar file is not managed by distro's package manager. You install, you yourself uninstall it too :P

[biggestsonicfan]

I have never installed mangohud manually as far as I know, if that's the random tar you are speaking of. Even if that was the case, why would the package manager not overwrite on install of a package? If the distro package manager knew it wasn't installed by itself, why would it say successful installation once it tried to install it's own managed version from a repo? I'm finding this situation extremely absurd and wanting to begin auditing every binary I have "installed".

Of course, if mangohud could have output a version number instead of saying "error this isn't a program lol" that might have been helpful as well.

EDIT: I'm now straying way offtopic for an already closed issue. Thank you for your assistance.

EDIT2: Upon further investigation, I booted into an older snapshot and sure enough /usr/lib/mangohud existed yet zypper/yast reported it wasn't installed. Normally if I compile and install something through git I keep that folder in my git folder, but apparently it was just so long ago I forgot, huh.

[DraconicCode]

mangohud in the Ubuntu repos is still 0.6.5-2 btw