The Vita builds of RetroArch and some libretro cores use these two
flags, supposedly to fix relocation-related bugs.
(cherry picked from commit 3c43cd5747b19bd4d9c0202fec1a68677ddbd5af)
I'd already removed the SDL static libraries from libretro builds for
portability, but kept the headers to make it easier to port the codebase
to libretro. Eventually it was time to stop using the SDL headers as a
crutch.
Okay, the coroutine implementation of `sandbox_malloc` is clearly
broken. It would be working if Asyncify instrumented the `memory.grow`
WebAssembly instruction, but it doesn't instrument it.
This commit reverts commit 42c4ff9497 and
also increases the default VM memory allocation from 64 MiB to 96 MiB to
account for the lack of ability to increase the memory allocation at run
time. I'll find some new way to implement increasing the memory
allocation later.
I was planning on using PortableGL as a software implementation of
OpenGL, but it's really slow (at least when compared to actual 2D
graphics software renderers). I'll have to actually add a separate
rendering backend for software rendering later instead of trying to
emulate OpenGL in software.
PortableGL supports shaders, but requires them to be compiled
ahead-of-time to C or C++.
I'll write a compiler later to translate from GLSL to this format
automatically at build time.
SDL disables OpenGL headers when building for iOS and tvOS, but that
causes our builds to fail. I'm getting conflicting answers on whether or
not OpenGL is supported on iOS and tvOS, but it's the libretro
frontend's job to care about this, not mine. Regardless, I'm gonna need
these OpenGL headers for software rendering on platforms with no OpenGL
support, so I can't tolerate the headers being disabled.
The only reason why WABT suggests this flag be used is because it
guarantees that infinite recursion will crash the program instead of
running in an infinite loop.
Honestly, who cares? It's not like either of these things are supposed
to happen, so from the viewpoint of the end user, they're basically the
same thing. I think we can afford to deviate from the WebAssembly
Specification here if it means allowing the compiler to do more
optimizations.
CMake object libraries keep building with position-independent code
enabled even when it's explicitly disabled! We do, in fact, have to
build with position-independent code disabled on some targets, such as
PlayStation Vita, since some targets support position-independent code.
CMake static libraries don't seem to forcibly enable
position-independent code, so I've converted all the object libraries
into static libraries and added the new static libraries as dependencies
in Meson.
It seems the length of the hash generated by
`git rev-parse --short HEAD` is nondeterministic. GitHub Actions
generates 7-character hashes, while my computer currently generates
8-character hashes. To be consistent, I'm forcing the hashes to be 7
characters long.
This way Meson will automatically keep the Git hash updated as you make
new Git commits, rather than forcing you to reconfigure the build again
every time you make a new commit to keep the commit hash updated.
(cherry picked from commit b9bb3535ae)
This removes the need to have xxd installed and provides a portable way
to specify the name of the output array (xxd has an `-n` option for
this, but it isn't present in older versions of xxd), which helps reduce
the possibility of symbol conflicts in libretro builds and also prevents
portability issues since the name of xxd's output array depends on the
relative path to the input file, which can break if Meson changes the
structure of the build directory or if the user sets the build directory
to a different location.
Also, this custom executable declares the array as const so that it goes
into the read-only data section of the binary instead of the data
section.
