I'll also add PlayStation Vita and Xbox once I figure out how.
Other than that, I think that's all the game consoles RetroArch supports
that aren't Linux-based!
This executor has the advantage of being able to work correctly when
there are Ruby stack frames underneath C/C++ stack frames in the stack.
Still need to implement handling Ruby fibers.
Apparently passing extra tools into `NATIVE_TOOLCHAIN` and
`WASI_TOOLCHAIN` in the phase 1 Makefile breaks libretro builds in
GitHub Actions - binaries built using those phase 1 files are unable to
start up the Ruby VM, although there are no compilation errors. Doesn't
happen when I build phase 1 on my computer though... Nonetheless, I've
removed the extra stuff from `NATIVE_TOOLCHAIN` and `WASI_TOOLCHAIN` in
the Makefile.
Also I've added code into the GitHub Actions workflows to strip the
libretro cores. Enabling LTO in GitHub Actions caused the libretro cores
produced to swell to enormous size compared to when built without LTO
due to the extra debug information added by LTO. However, with stripping
enabled, stripped binaries built with LTO are actually somewhat smaller
than stripped binaries built without LTO.
We can't have them as normal functions because reentrant calls into the
Ruby API don't work if you do that, i.e. calling into the Ruby API and
that calls mkxp-z's bindings and that calls back into the Ruby API.
* Ruby is no longer required to be already installed to build phase 1
* Commands and versions for everything are now configurable
* The `-j` Make flag is now respected
The old arguments were invoking undefined behaviour that may or may not
cause crashes when initializing Ruby depending on which path on the
build machine Ruby was built on!
WebAssembly is little-endian regardless of what machine you run it on,
so the WebAssembly implementation needs to know if the machine is
big-endian or little-endian to function properly.
Apparently `environ` is some kind of reserved word in MSYS2's build
environment, which caused hard-to-understand linking errors on Windows
due to one of the functions in wasi.cpp having an argument named
`environ`. I've changed the name of the offending argument to `env`.
I've also added `extern "C"` to all exported functions to make sure
something like this doesn't happen again - the compiler should now
refuse to compile the code if there are function signature mismatches in
exported functions.
Right now I've implemented opening game files that are in zip format and
added a filesystem implementation to allow reading the game files. I've
also added a `Dir.glob` call core.cpp to print the contents of the root
directory of the game zip file to the log as a test.
