RetroPie forum home
    • Recent
    • Tags
    • Popular
    • Home
    • Docs
    • Register
    • Login

    lr-mupen64plus doesn't compile on Ubuntu 20.10

    Scheduled Pinned Locked Moved
    Ideas and Development
    build failed lr-mupen64plus retropie x86 ubuntu 20.10
    3
    9
    985
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • ethelingE
      etheling
      last edited by 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
      BuZzB 1 Reply Last reply Reply Quote 0
      • mituM
        mitu Global Moderator
        last edited by 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.

        BuZzB 1 Reply Last reply Reply Quote 0
        • BuZzB
          BuZz administrators @mitu
          last edited by 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.

          To help us help you - please make sure you read the sticky topics before posting - https://retropie.org.uk/forum/topic/3/read-this-first

          ethelingE 1 Reply Last reply Reply Quote 1
          • ethelingE
            etheling @BuZz
            last edited by

            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:~$
            ethelingE 1 Reply Last reply Reply Quote 0
            • ethelingE
              etheling @etheling
              last edited by 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
>
              BuZzB 1 Reply Last reply Reply Quote 1
              • BuZzB
                BuZz administrators @etheling
                last edited by

                @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.

                To help us help you - please make sure you read the sticky topics before posting - https://retropie.org.uk/forum/topic/3/read-this-first

                ethelingE 1 Reply Last reply Reply Quote 0
                • BuZzB
                  BuZz administrators @etheling
                  last edited by

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

                  To help us help you - please make sure you read the sticky topics before posting - https://retropie.org.uk/forum/topic/3/read-this-first

                  ethelingE 1 Reply Last reply Reply Quote 0
                  • ethelingE
                    etheling @BuZz
                    last edited by

                    @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.

                    1 Reply Last reply Reply Quote 0
                    • ethelingE
                      etheling @BuZz
                      last edited by

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

                      1 Reply Last reply Reply Quote 0
                      • First post
                        Last post

                      Contributions to the project are always appreciated, so if you would like to support us with a donation you can do so here.

                      Hosting provided by Mythic-Beasts. See the Hosting Information page for more information.