Retropie compilation on Debian (testing branch with new gcc)

eloranta

Hi,

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

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

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

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?

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

mitu

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

eloranta

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.