lr-mupen64plus doesn't compile on Ubuntu 20.10

[etheling]

Error message below. This is likely caused because Ubuntu 20.10 (x64) upgraded to GCC 10.x. To get it compile, #include <string>has to be added to GLideN64/src/ShaderUtils.h and CFLAGS in Makefile has to include -fcommon. Below is a rough .patch for lr-mupen64plus. sh that makes it compile on Ubuntu 20.10 so that 'setup basic_install' passes. I didn't test if mupen64plus actually works after these changes. For CFLAGS, there's probably a more appropriate place for '-fcommon' than where it's now brute forced.

Patch for ...RetroPie-Setup/scriptmodules/libretrocores/lr-mupen64plus.sh:

50a51,69
>     
>     echo "md_build: "
>     echo "md_data: "
>     pwd
>     cp ./Makefile ./Makefile.orig
>     cp ./GLideN64/src/ShaderUtils.cpp ./GLideN64/src/ShaderUtils.cpp.orig
>     cat << EOF >> ./Makefile.patch
> 403c403
> < CFLAGS      += \$(CPUOPTS) \$(COREFLAGS) \$(INCFLAGS) \$(PLATCFLAGS) \$(fpic) \$(CPUFLAGS) \$(GLFLAGS) \$(DYNAFLAGS)
> ---
> > CFLAGS      += -fcommon \$(CPUOPTS) \$(COREFLAGS) \$(INCFLAGS) \$(PLATCFLAGS) \$(fpic) \$(CPUFLAGS) \$(GLFLAGS) \$(DYNAFLAGS)
> 
> EOF
>     cat << EOF >> ./GLideN64/src/ShaderUtils.cpp.patch
> 2a3
> > #include <string>
> EOF
>     patch ./Makefile ./Makefile.patch
>     patch ./GLideN64/src/ShaderUtils.cpp ./GLideN64/src/ShaderUtils.cpp.patch

First error message:

...
Getting sources for 'lr-mupen64plus' : N64 emu - Mupen64Plus + GLideN64 for libretro
= = = = = = = = = = = = = = = = = = = = =
 
git clone --recursive --depth 1 --branch master "https://github.com/libretro/mupen64plus-libretro.git" "/home/pi/RetroPie-Setup/tmp/build/lr-mupen64plus"
....
/home/pi/RetroPie-Setup/tmp/build/lr-mupen64plus /home/pi
 
= = = = = = = = = = = = = = = = = = = = =
Building 'lr-mupen64plus' : N64 emu - Mupen64Plus + GLideN64 for libretro
...
...
g++   -march=native -O2 -fvisibility-inlines-hidden -std=c++11 -O2 -DNDEBUG -fsigned-char -ffast-math -fno-strict-aliasing -fomit-frame-pointer -fvisibility=hidden -DGIT_VERSION=\"" ab8
134a"\" -DOS_LINUX -DARCH_MIN_SSE2 -msse -msse2 -D__LIBRETRO__ -DUSE_FILE32API -DM64P_PLUGIN_API -DM64P_CORE_PROTOTYPES -D_ENDUSER_RELEASE -DSINC_LOWER_QUALITY -DTXFILTER_LIB -D__VEC4_O
PT -DMUPENPLUSAPI -I./custom -I./custom/mupen64plus-core -I./custom/android/include -I./custom/GLideN64 -I./GLideN64/src -I./GLideN64/src/osal -I./mupen64plus-core/src -I./mupen64plus-c
ore/src/api -I./custom/mupen64plus-core/plugin/audio_libretro -I./libretro-common/include -I./libretro -I./GLideN64/src/inc -I./xxHash -I./libretro-deps/libpng  -fPIC  -DCORE -DHAVE_OPE
NGL -DDYNAREC -c GLideN64/src/ShaderUtils.cpp -o GLideN64/src/ShaderUtils.o
In file included from GLideN64/src/ShaderUtils.cpp:3:
GLideN64/src/ShaderUtils.h:10:52: error: ‘string’ in namespace ‘std’ does not name a type
   10 | void logErrorShader(GLenum _shaderType, const std::string & _strShader);
      |                                                    ^~~~~~
GLideN64/src/ShaderUtils.h:6:1: note: ‘std::string’ is defined in header ‘<string>’; did you forget to ‘#include <string>’?
    5 | #include "Combiner.h"
  +++ |+#include <string>
    6 | 
GLideN64/src/ShaderUtils.h:11:93: error: ‘std::string’ has not been declared
   11 | int compileCombiner(const gDPCombine & _combine, Combiner & _color, Combiner & _alpha, std::string & _strShader);
      |                                                                                             ^~~~~~
make: *** [Makefile:433: GLideN64/src/ShaderUtils.o] Error 1
make: *** Waiting for unfinished jobs....
Removing additional swap
/home/pi
Could not successfully build lr-mupen64plus - N64 emu - Mupen64Plus + GLideN64 for libretro (/home/pi/RetroPie-Setup/tmp/build/lr-mupen64plus/mupen64plus_libretro.so not found).
Errors:
Could not successfully build lr-mupen64plus - N64 emu - Mupen64Plus + GLideN64 for libretro (/home/pi/RetroPie-Setup/tmp/build/lr-mupen64plus/mupen64plus_libretro.so not found).
No module 'splashscreen' found for platform x86
   0  

edit: some system info:

pi@retropie ~ $ uname -a
Linux retropie 5.8.0-25-generic #26-Ubuntu SMP Thu Oct 15 10:30:38 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
pi@retropie ~ $ lsb_release -a
No LSB modules are available.
Distributor ID:	Ubuntu
Description:	Ubuntu 20.10
Release:	20.10
Codename:	groovy
pi@retropie ~ $ gcc --version
gcc (Ubuntu 10.2.0-13ubuntu1) 10.2.0

[mitu]

The patches should be sent upstream, but Mupen64plus core is archived at this point, so that won't work. We could remove it as default/optional for x86 and promote Mupen64plus-Next instead.

[BuZz]

@mitu I agree with that.

@etheling On a modern PC the lr-parallel-n64 core is probably the most accurate - depending on your system specs.

[etheling]

I'm sorry to be the bearer of bad news, but looks like lr-puae also fails because of toolchain / glibc updates on Ubuntu 20.10.

Here's the log (did quickly test that it compiles normally on 20.04 LTS):

pi@retropie:~$ sudo /home/pi/RetroPie-Setup/retropie_packages.sh lr-puae
...
...
cc -fPIC  -march=native -O2 -O3 -D__LIBRETRO__ -DINLINE="inline" -std=gnu99 -DGIT_VERSION=\"" 12918bf"\"   -I./sources/src -I./sources/src/include -I./libretro -I./libretro-common/include -I./retrodep -I. -I./deps/zlib -c -o retrodep/memory.o retrodep/memory.c
retrodep/memory.c:21:10: fatal error: sys/sysctl.h: No such file or directory
   21 | #include <sys/sysctl.h>
      |          ^~~~~~~~~~~~~~
compilation terminated.
make: *** [Makefile:291: retrodep/memory.o] Error 1
make: *** Waiting for unfinished jobs....
/home/pi
Could not successfully build lr-puae - P-UAE Amiga emulator port for libretro (/home/pi/RetroPie-Setup/tmp/build/lr-puae/puae_libretro.so not found).
Errors:
Could not successfully build lr-puae - P-UAE Amiga emulator port for libretro (/home/pi/RetroPie-Setup/tmp/build/lr-puae/puae_libretro.so not found).
pi@retropie:~$ 
 

[etheling]

I had a few minutes to look at this today. Looks like sysctl(mib, 2, &totalphys64, &len, NULL, 0); is only used inside #ifdef __APPLE__ block in retrodep/memory.c. It feels pretty safe to wrap #include <sys/sysctl.h> to #ifdef __APPLE__ to make this problem disappear. After that, and adding -fcommon to CFLAGS lr-puae compiles again on Ubuntu 20.10.

Grep tells me that also sources/src/od-generic/memory.c has similar sysctl construct, but since it's not used in this configuration, I didn't touch it.

Caveat emptor - these changes sort of sweep the problem under the rug. Although I don't see how these changes would break lr-puae functionality-wise or it's compilation on other platforms, I only tested it compiles and loads up on x64/Ubuntu 20.10 . Also, that #include <sys/sysctl.h> is already inside a block of #ifndefs so there's probably better ways to fix that than what I did here. Lastly, I feel a bit that adding -fcommon is just putting bandage over something that should be fixed elsewhere. But at least in the interim this gets lr-puae compiled.

Here's the patch files for the changes:

Makefile.patch:

269c269
< CFLAGS += -D__LIBRETRO__ -DINLINE="inline" -std=gnu99
---
> CFLAGS += -fcommon -D__LIBRETRO__ -DINLINE="inline" -std=gnu99

retrodep/memory.c.patch:

20a21
> #ifdef __APPLE__
21a23
> #endif

Or both in RetroPie-Setup/scriptmodules/libretrocores/lr-puae.sh.patch:

22a23,41
>     if isPlatform "x86"; then
> 	cat << EOF >> ./Makefile.patch
> 269c269
> < CFLAGS += -D__LIBRETRO__ -DINLINE="inline" -std=gnu99
> ---
> > CFLAGS += -fcommon -D__LIBRETRO__ -DINLINE="inline" -std=gnu99
> EOF
> 	cat << EOF >> ./retrodep/memory.c.patch
> 20a21
> > #ifdef __APPLE__
> 21a23
> > #endif
> EOF
> 	cp -v ./Makefile ./Makefile.orig
> 	cp -v ./retrodep/memory.c ./retrodep/memory.c.orig
> 	patch ./Makefile ./Makefile.patch
> 	patch ./retrodep/memory.c ./retrodep/memory.c.patch	
>     fi
> 

[BuZz]

@etheling I have forked the repo here - https://github.com/RetroPie/mupen64plus-libretro

If you submit a PR I can include the fix - or I can do it myself if you prefer.

[BuZz]

@etheling fixes for the puae libretro core can be sent to https://github.com/libretro/libretro-uae

[etheling]

@BuZz I sent you PR. I hope it's ok. I can do one for lr-puae tomorrow too and see if it gets accepted, or if devs would rather work on those missing externs etc.

[etheling]

@BuZz Just a heads up that libretro-uae accepted the fix and merged it to master.