can't use Mupen64Plus (chooses Ares64 instead) Arch Linux

[AStupidPerson3141]

this is my first issue, so if I do something wrong, please let me know!

a few years ago, I was using Bizhawk on Windows, and could use Mupen64Plus. Now I'm on Arch Linux (x86_64), and running both the .zip and the .n64 files result in BizHawk using Ares64 instead of Mupen64Plus. I tried using the aur and downloading the release (2.9.1), both of which used Ares instead of the preferred Mupen64plus core. I even tried using wine, but that crashes upon loading the ROM.

the log (EmuHawkMono_laststdout.txt)

Using OpenTK 3 for host input (keyboard + gamepads)
MemoryBlock created for address 36f00000000:36f23afd000 with mirror 7e2d6eafe000:7e2d925fb000
Mouting `ares64_recompiler.wbx` @36f00000000
  Sections:
    @0:0     `` 0 bytes
    @36f00000270:36f00000288 R   `.note.gnu.build-id` 24 bytes
    @36f00001000:36f00001003 R X `.init` 3 bytes
    @36f00001010:36f001bc961 R X `.text` 1816913 bytes
    @36f001bc961:36f001bc964 R X `.fini` 3 bytes
    @36f001bd000:36f001d5c6c R   `.rodata` 101484 bytes
    @36f001d5c6c:36f001dd660 R   `.eh_frame_hdr` 31220 bytes
    @36f001dd660:36f00210390 R   `.eh_frame` 208176 bytes
    @36f00210390:36f002161b0 R   `.gcc_except_table` 24096 bytes
    @36f00217000:36f00217198 RW  `.init_array` 408 bytes
    @36f00217198:36f00217198 RW  `.fini_array` 0 bytes
    @36f00218000:36f0039ea80 RW  `.invis` 1600128 bytes
    @36f0039f000:36f0039f43c RW  `.data` 1084 bytes
    @36f003a0000:36f020f9690 RW  `.bss` 30774928 bytes
    @36f020fa690:36f020fa690 RW  `.ldata` 0 bytes
    @0:6f     `.comment` 111 bytes
    @0:25488     `.symtab` 152712 bytes
    @0:ac     `.shstrtab` 172 bytes
    @0:4cd4d     `.strtab` 314701 bytes
  Segments:
    %36f00000040:36f00000270 R   560 bytes
    %36f00000000:36f00000288 R   648 bytes
    %36f00001000:36f001bc964 R X 1816932 bytes
    %36f001bd000:36f002161b0 R   364976 bytes
    %36f00217000:36f00217198 RW  408 bytes
    %36f00218000:36f020fa690 RW  32384656 bytes
    %36f00217000:36f00218000 R   4096 bytes
   %36f001d5c6c:36f001dd660 R   31220 bytes
   %36f00000270:36f00000288 R   24 bytes
Calling _start()
Initializing heap sbrk at 36f022fb000:36f024fb000
Allocated 4096 bytes on sbrk heap, usage 4096/2097152
Allocated 4096 bytes on sbrk heap, usage 8192/2097152
Allocated 4096 bytes on sbrk heap, usage 12288/2097152
Initializing heap invisible at 0x36f024fc000:0x36f03afc000
Allocated 4096 bytes on invisible heap, usage 4096/23068672
Allocated 4096 bytes on sbrk heap, usage 16384/2097152
Allocated 4096 bytes on sbrk heap, usage 20480/2097152
Allocated 4096 bytes on sbrk heap, usage 24576/2097152
Allocated 1474560 bytes on invisible heap, usage 1478656/23068672
Allocated 1474560 bytes on invisible heap, usage 2953216/23068672
Allocated 1474560 bytes on invisible heap, usage 4427776/23068672
Allocated 1474560 bytes on invisible heap, usage 5902336/23068672
Allocated 8192 bytes on sbrk heap, usage 32768/2097152
Allocated 8192 bytes on sbrk heap, usage 40960/2097152
Allocated 69632 bytes on sbrk heap, usage 110592/2097152
Allocated 69632 bytes on sbrk heap, usage 180224/2097152
Allocated 73728 bytes on sbrk heap, usage 253952/2097152
Allocated 73728 bytes on sbrk heap, usage 327680/2097152
Allocated 69632 bytes on sbrk heap, usage 397312/2097152
Allocated 135168 bytes on sbrk heap, usage 532480/2097152
Allocated 102400 bytes on sbrk heap, usage 634880/2097152
Calling co_clean()
Calling ecl_seal()
WaterboxHost Sealed!
CPU allocator flush

[Morilli]

I feel like there should be a similar issue, but maybe it was on discord. Short answer is: mupen64 is currently only supported on windows, not on linux.

The core has never been compiled for linux and in its current state also wouldn't be compilable because of hard windows dependencies. I have started working on updating the mupen64 core (the current one is very old already) which would also include a linux variant, but because of unresolved issues with it it's currently on hold.

For now your options are to use ares64 or run bizhawk on windows somehow.

[AStupidPerson3141]

Thanks! This answers my question, so I'll close the issue for now

[YoshiRulz]

(Or use a different Mupen frontend if you don't need rerecording.)

The fact that it doesn't work is mentioned somewhere in #1430.