Recent mupen64plus/m64py update appears to break libmupen64plus2


I updated my system today and noticed m64py stopped working, saying “Mupen64Plus library not found.”. The message repeats after setting the path for the library (in the settings menu which accompanies on startup), and when setting the path for the plugins directory the application just crashes.

After trying to start mupen64plus from the terminal, this is what I get:

UI-Console Error: dlopen('/usr/lib64/') failed: /usr/lib64/ undefined symbol: _hex_value
UI-Console Error: dlopen('./') failed: ./ cannot open shared object file: No such file or directory
UI-Console Error: AttachCoreLib() Error: failed to find Mupen64Plus Core library

I also tried “zypper in -f libmupen64plus2”, but it didn’t change anything. Since is just a link pointing to I also tried passing the path directly to it, but it changed nothing.

The Mupen packages are not in Tumbleweed, so please show

zypper lr -d

Was ‘zypper dup’ used to update Tumbleweed?

The packages come from here from what I see in Software Management.

4 | openSUSE_Tumbleweed_3 | Emulators                   | Yes     | (r ) Yes  | Yes     |   99     | rpm-md |


There was another update 2 days ago, but it didn’t change anything.

Some extra information though (‘sudo zypper search -s libmupen64plus2’):

S | Name            | Type    | Version   | Arch   | Repository
i | libmupen64plus2 | package | 2.5.9-1.2 | x86_64 | Emulators 
v | libmupen64plus2 | package | 2.5.9-1.2 | i586   | Emulators

This is the only version available from the repo now, which means I can’t downgrade to whatever the previously working version was, which from zypp history should be (‘sudo cat /var/log/zypp/history | grep libmupen64plus2’):

2019-04-20 XX:XX:XX|install|libmupen64plus2|2.5-2.22|x86_64||openSUSE_Tumbleweed_longnumberredacted

Wish you could edit posts here. Anyway, I have another update.

I tried to rebuild mupen64plus-2.5.9-1.2.src.rpm from the Emulators repository using rpm-build. After installing a few things I was missing I hit a dead end, with dependencies failing for:

        pkgconfig(freetype2) is needed by mupen64plus-2.5.9-1.2.x86_64
        pkgconfig(libpng) is needed by mupen64plus-2.5.9-1.2.x86_64
        pkgconfig(samplerate) is needed by mupen64plus-2.5.9-1.2.x86_64
        pkgconfig(sdl2) is needed by mupen64plus-2.5.9-1.2.x86_64

pkgconfig is already provided by pkg-config. And you see the same trend when trying to install the other stuff here:

'freetype2' not found in package names. Trying capabilities.
'libfreetype6' providing 'freetype2' is already installed.
'libpng' not found in package names. Trying capabilities.
'libpng16-16' providing 'libpng' is already installed.
'SDL2' not found in package names. Trying capabilities.
'libSDL2-2_0-0' providing 'SDL2' is already installed.
'samplerate' not found in package names. Trying capabilities.
No provider of 'samplerate' found.

Could this be the source of the issue?

Did you install the respective development packages…?

For example;

zypper in pkgconfig\(freetype2\)

Neat. That worked.

After installing the built rpms though, I’m back to square one. I tried only installing libmupen64plus2 first, but even after installing the rest there was no change.

You would need to install all the needed rpms from the ones you built locally just to make sure. But sounds like a bug as the build looks ok…

I still have the built rpms, so I tried also installing the libmupen64plus-devel package, but still no change. Should I have removed the packages which were installed from the repo before trying to install the locally built ones? When updating the system it asks for a vendor change on the mupen64plus related packages, so it would seem they installed without issue. I didn’t keep the build log (unless it’ got stored somewhere), but it seemed fine for me too.

When m64py crashes after browsing and setting the plugins directory path, there’s a longer crash report (with repeating information from what I can tell). Not sure if it helps.

There’s some complaints about, but I’m not sure how related it is. I have a HP Envy x360 15" (Ryzen with Vega graphics).

The radeonsi_dri is used by amdgpu as well :wink: But that seems qt related? What desktop environment?

If you run the command (as root user) ldconfig and then try again as your user how does it go?


As root the command runs without any output on the terminal. As user it fails, saying it needs superuser privileges.

Apologies, I meant the emulator as your user :wink: The ldconfig as root to re-create any library links…

And you all up to date via a zypper dup?

lol, dunno how I managed to misunderstand that. Yeah, there’s no change unfortunately, and the system is up to date.

The clue has to be somewhere in the error message about some undefined hex value symbol. It’s as if the core library can’t be read.

Sounds like it might be time to create a bug report…
openSUSE:Submitting bug reports - openSUSE

I see there has been a few commits since it was updated…

Did you install the respective development packages…?