openal-soft assumes that aligned_alloc is available with c++17. Newer
android ndks set c++17 by default, however they do not expose
aligned_alloc without setting min sdk version to 28.
We can avoid this issue by forcing openal to be compiled with c++11.
Also note, we have HXCPP_CPP11 defined, however, hxcpp ignores this for
the android toolchain. This means we must set it explicitly
See:
f5e0eef34d/common/almalloc.cpp (L15)
Hxcpp doesn't respect HXCPP_CPP11 for android. We can avoid this issue just by adding -std=c++11 here. This resolves a conflict with openal soft 1.20.1 for android builds. This works because the library assumes c++17 and invokes a function that isn't available in android sdk below 28.
clang: warning: include path for libstdc++ headers not found; pass '-stdlib=libc++' on the command line to use the libc++ standard library instead [-Wstdlibcxx-not-found]
Device orientation is the orientation of the phone/tablet.
Display orientation is the orientation of what is rendered on the display.
By default, they should usually be the same. If orientation is locked, device orientation will update, but display orientation usually won't.
This allows us to upgrade freetype beyond 2.9.1 (actually, 2.8.1 due to a bug in freetype 2.9) without wildly different font metrics. The reason that we don't want to change font metrics algorithms is that freetype's new algorithm is very different than the algorithm used for SWF fonts. The older freetype algorithm is closer to SWF, so we want to stick with it.
Thankfully, freetype supports accessing various metrics stored in font files in a more raw form, so we can provide our own custom algorithm in a way that is fully supported by freetype. I just copied the existing algorithm straight from 2.9.1 to restore our preferred behavior.
I confirmed that, after this change, OpenFL renders metrics like Lime 8.1.3. But we have the same upgraded freetype as Lime 8.2.0 that we had to revert for 8.2.1.
I plan to experiment with a mode that matches SWF even more closely, now that I have a better understanding of how fonts and freetype work.
Previously, we added these rpaths to lime.ndll when it was built in commits c70ec9f and 333d093, but it's actually necessary only for Neko, so now I made it happen specfically after calling `nekotools boot` to create the Neko executable.
I've tested cpp and hl, and I've confirmed that the executables still launch successfully when these rpaths are omitted. It's better for their security to use fewer rpaths.
As noted commit c70ec9f, adding these rpaths is necessary due to a change in Xcode 15 where /usr/local/lib used to be available on the rpath automatically, but now it isn't, which affects the executable's ability to find the libneko dylib.
This is where arm64 homebrew installs `libneko.dylib`. However, it may still be in `/usr/local/lib` if installed via the haxe .pkg installer, so we add both.
