Please do not post a support request without first reading and following the advice in https://retropie.org.uk/forum/topic/3/read-this-first

Retropie compilation on Debian (testing branch with new gcc)


  • Hi,

    I ran into couple of issues on Debian (testing branch).

    1. GCC version: gcc version 10.2.0 (Debian 10.2.0-6)

    Problem compiling Mupen64Plus:

    ...
    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="" ab8134a"" -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_OPT -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-core/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_OPENGL -DDYNAREC -c GLideN64/src/TextureFilterHandler.cpp -o GLideN64/src/TextureFilterHandler.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);
    | ^~~~~~
    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="" ab8134a"" -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_OPT -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-core/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_OPENGL -DDYNAREC -c GLideN64/src/PostProcessor.cpp -o GLideN64/src/PostProcessor.o
    make: *** [Makefile:433: GLideN64/src/ShaderUtils.o] Error 1
    make: *** Waiting for unfinished jobs....
    Removing additional swap
    /home/eloranta/RetroPie-Setup
    Could not successfully build lr-mupen64plus - N64 emu - Mupen64Plus + GLideN64 for libretro (/home/eloranta/RetroPie-Setup/tmp/build/lr-mupen64plus/mupen64plus_libretro.so not found).

    =====

    Suggested fix:

    Change the file lr-mupen64plus/GLideN64/src/ShaderUtils.h as suggested by the compiler:

    #ifndef SHADER_UTILS_H
    #define SHADER_UTILS_H

    #include <string> // THIS LINE WAS ADDED

    #include "OpenGL.h"
    #include "Combiner.h"

    GLuint createShaderProgram(const char * _strVertex, const char * _strFragment);
    bool checkShaderCompileStatus(GLuint obj);
    bool checkProgramLinkStatus(GLuint obj);
    void logErrorShader(GLenum _shaderType, const std::string & _strShader);
    int compileCombiner(const gDPCombine & _combine, Combiner & _color, Combiner & $

    #endif // SHADER_UTILS_H

    =======================================================================

    1. Multiply defined symbols when linking the new routines into libretro:

    /usr/bin/ld: ./mupen64plus-rsp-cxd4/su.o:(.bss+0x108): multiple definition of DMEM'; ./GLideN64/src/N64.o:(.bss+0x1108): first defined here /usr/bin/ld: ./mupen64plus-rsp-cxd4/su.o:(.bss+0x100): multiple definition of IMEM'; ./GLideN64/src/N64.o:(.bss+0x1100): first defined here
    /usr/bin/ld: ./custom/mupen64plus-core/main/main.o:(.bss+0x802c78): multiple definition of libretro_swap_buffer'; ./custom/GLideN64/mupenplus/OpenGL_mupenplus.o:(.bss+0x1): first defined here /usr/bin/ld: ./mupen64plus-core/src/main/savestates.o:(.bss+0x0): multiple definition of work'; ./custom/mupen64plus-core/api/frontend_libretro.o:(.bss+0x0): first defined here
    /usr/bin/ld: ./libretro/libretro.o:(.bss+0x488f8): multiple definition of `libretro_swap_buffer'; ./custom/GLideN64/mupenplus/OpenGL_mupenplus.o:(.bss+0x1): first defined here
    collect2: error: ld returned 1 exit status
    make: *** [Makefile:420: mupen64plus_libretro.so] Error 1

    As far as I can tell, one might just be able to change the variable names so that they do not conflict?

    1. Something has changed with dialog package or bash or both (?). For most retropie setup script items I am getting:

    /home/eloranta/RetroPie-Setup/scriptmodules/admin/setup.sh: line 149:
    Error: Unknown option Choose an option.
    Use --help to list options.: syntax error in expression (error token is ": Unknown option Choose an option.
    Use --help to list options.")

    I ran the script with strace and I can see that it indeed calls dialog with empty --default-item . As far as I can tell, all bash scripts include express the argument as "$default" etc. so that even if the variable is empty, it should still pass --default-item "". Any ideas what is going on?

    Jussi

  • Global Moderator

    @eloranta said in Retropie compilation on Debian (testing branch with new gcc):

    Something has changed with dialog package or bash or both (?). For most retropie setup script items I am getting:

    Probably your system is not detected correctly, being on the testing branch. For the issues regarding mupen64plus - those should be submitted upstream, but that libretro core repository is now archived and will not accept changes - use the mupen64plus-next core instead.


  • In scriptmodules/system.sh:

            # Debian unstable is not officially supported though
            if [[ "$__os_release" == "unstable" ]]; then
                __os_debian_ver=11
            fi
    

    So, I added the following after this:

            if [[ "$__os_release" == "testing" ]]; then
                __os_debian_ver=11
            fi
    

    This did not change anything (or using 10 there). So, this is likely a bit more than not detecting the debian version correctly.

    The only issue with mupen64plus is that the system will try to compile that by default during installation and this ends up in error.

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.