This matches the behavior of cmake. Besides that we have some optional
C11 code and it should be used if the compiler has support for it. And
C99 as default is a remnant from the old times were we didn't want C11
in the standard code path, because several old Linux distros didn't
support it...
This ensures that we call ARM64 `aarch64` on all platform, which aren't
MacOS or Windows. And it fixes the bug, that `arm64` was normalized to
`arm`, making incompatible savegames between 32 bit and 64 bit ARM
loadable. Leading to crashes.
At least for LLVM / Clang the -fsanitize= option must be passed to the
linker before any objects or libraries, otherwise the sanitizers will
either noch link or are disfunctional. Split LDFLAGS into LDFLAGS for
flags and LDLIBS for librariers, pass LDFLAGS before any objects and
LDLIBS after all objects. While at it set RTLD_NODELETE so that shared
libs opened by dlopen() are never deleted from memory when building
with sanitizers.
While this shouldn't be a problem with C code, better be safe than
sorry. @DanielGibson stumbled over this while debugging some strange
RB-Doom3 / dhewm3 issues with gcc. See this bug report for details:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100839
$PROCESSOR_ARCHITECTURE seems to contain the architecture of the host,
but we need the architecture the current MinGW shell is targeting.
$MINGW_CHOST seems to be just that, and on my system it's either
i686-w64-mingw32 (mingw32.exe) or x86_64-w64-mingw32 (mingw64.exe)
(No idea what it looks like for Windows on ARM...)
As fixing this would otherwise break existing savegames, I bumped the
SAVEGAMEVER to "YQ2-4" and added a quirk for older savegameversions:
On Windows i386 savegames that contain "AMD64" instead of "i386" as
architecture are also accepted.
(For YQ2-1 this didn't seem necessary, apparently "i386" was hardcoded)
