Workaround g++-12 compiler bug/compilation issue on 32bit arm userland with aarch64 kernel on the rpi3 (cortex-a53)
Disabling -ftree-slp-vectorize works around the issue:
{standard input}: Assembler messages:
{standard input}:4045: Error: co-processor offset out of range
make[2]: *** [skeleton.make:2727: obj/Release/src/mame/skeleton/scopus.o] Error 1
Add arch_opts_cxx array to handle adding additional parameters to ARCHOPTS_CXX.
Seems like setting `LDFLAGS` is not enough (anymore) to strip debugging info from the binaries.
Use `ARCHOPTS` instead, as the build documentation recommends.
Force PLATFORM=arm on arm systems. Without this mame builds for aarch64 and sets PTR64=1 erroring out with:
static_assert(sizeof(void *) == 8, "PTR64 flag enabled, but was compiled for 32-bit target\n");
This also fixes building of lr-mame2016
* MAME specifically checks for GCC 10.3 so we need to compare with the full GCC version as bullseye has 10.2.
* lr-mame - Remove "master" branch from rp_module_repo so the _get_version tag is passed as a branch to checkout
* lr-mame - Simplify _get_version_lr-mame as the tagname variable was only used once
Starting with version 0.265 (April 2024), GCC 10.3 is required for building MAME.
Enforce this requirement when building the emulator and libretro cores, Debian Buster will be getting 0.264 as the last version.
Version 0.263 introduced support for ZSTD compression for CHD files, but the version in Debian 10 Buster is not recent enough to compile MAME. Use the bundled source for `libzstd` instead of the system provided libraries for now.
Made a few tweaks to optimize bulding MAME:
- bump the RAM requirements, to ensure there's enough memory to complete the build.
- don't build the MAME debugger on non-desktop platforms, since it would need a windowing environment to run anyway.
This allows us to remove the QT dependencies and debugger compilation steps.
- use system's flac/zstd libraries (more could be added)
- tell the linker to remove debugging info, so the binaries don't need a 'strip' call afterwards
- synchronize the optimization level in MAME with RetroPie's optimization flags (-O2), to avoid extra optimization during compiling (MAME defaults to '-O3').
Latest mame has an issue linking on Raspberry Pi OS Bullseye. It fails with
/usr/bin/ld: BFD (GNU Binutils for Raspbian) 2.35.2 assertion fail ../../bfd/elf32-arm.c:9876
Work around this by using the gold linker.
Forcing 'char' to be signed fixes crashing in some drivers, needed on ARM.
The default behavior for 'char' is arch/ISA specific, see:
https://stackoverflow.com/questions/46463064
gcc -dumpversion on GCC >= 7 seems to provide the major version but the documentation suggests this depends on how it's configured.
We only need to test the major version so using compareVersions isn't required.
https://gcc.gnu.org/onlinedocs/gcc/Developer-Options.html states:
>Print the compiler version (for example, 3.0, 6.3.0 or 7)—and don’t do anything else. This is the compiler
>version used in filesystem paths and specs. Depending on how the compiler has been configured it can be
>just a single number (major version), two numbers separated by a dot (major and minor version) or three
>numbers separated by dots (major, minor and patchlevel version).
Ensure __gcc_version only contains the major version just in case in system.sh
The change impacts `lr-mame`,`lr-mess`,`lr-mame2016`,`lr-mess2016` and `mame`.
It should fix building on new Ubuntu 20.04+ installations, which don't have a default `python` executable.
Since `python3` is automatically needed by the installation (via `python3-pyudev` for `joy2key`), no explicit dependency for `python3` was added.
