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.
Was added due to issues building in emulated chroot. May add another flag for that,
but we are currently using a rpi4 to build binaries so it's not an issue.
* Makefile.libretro now tries to get the current git tag, which can fail if tags havent been downloaded - code looks somewhat risky, but we can override the failing part with a make var
* makefile patch is still needed for our compiler flags
* CPU_FLAGS isn't used so not sure what happened here - mistake or I missed out something.
* use CXXFLAGS for the additional videocore flags, to override makefile logic
* re-add make clean
Makefile for lr-flycast has a lot of copy and paste and unneeded compiler parameters. Although moving the
logic to the module could still break with Makefile changes, it gives us more control over both
compiler parameters, as well as adding other platforms without having to upstream changes.
Removed !mali flag but this will need testing still. Current changes are tested on rpi+videocore, rpi+mesa,
and rpi4(aarch64)+mesa
Also removed DISTCC workaround as this is now built without Link Time Optimisation. The Makefile patch is also
dropped, as this is no longer needed.
lr-gpsp:
cpu_threaded.c built with -O2 on gcc 8 produces a non working binary. This source already had
a different optimisation level from the rest of the code (O2 vs O3). However, on gcc-8 it causes
a non working binary when built with anything other than O0, but this could have some performance
issues (would need testing on a rpi1).
I compared all the different optimisation flags enabled by O1 and also with any changes from gcc-6,
but not all GCC optimisations are controllable from flags. It was not possible to produce a working
binary with O1 - even disabling all the configurable optimisations enabled by O1.
The issue is most likely undefined behaviour in this file (which has a lot of large macros), and it
probably needs some fixes. However it could be a bug in the gcc-8 optimiser code.
As the issue isn't present with gcc-6, and as gcc-6 is available on Debian buster, the easiest
workaround is to just force the code to be build with gcc-6.
Also adjusted the makefile to pass parameters for the make clean, as some platform specific objects
are not removed otherwise.
gpsp:
Forced gcc-6 as with lr-gpsp.
Simplified the module flags to just include videocore platforms.
Was added due to issues building in emulated chroot. May add another flag for that,
but we are currently using a rpi4 to build binaries so it's not an issue.
Older GCC on at least Debian used to output a 3 part version like 6.3.0 with gcc -dumpversion
Newer GCC / OS seems to only output the major version which broke comparisons as dpkg will consider a version such as "6" to be lower than 6.0.0
