Joshua Root
The change resulting from Bug 4208 changed the compatibility_version of libSDL2 from 9.0.0 to 1.0.0. This is simply wrong.
This means that programs linked against 2.0.9 are considered by the dynamic linker to be compatible with all previous versions of libSDL2. This is not the case since new public symbols have been added.
The way compatibility_version and current_version are meant to work is:
* current_version increases every time the library changes in any way.
* compatibility_version is increased to match current_version whenever new public symbols are added.
Thus both versions should only ever increase. The solution to the Xcode project and autotools not having matching versions should have been to increase the version(s) in the Xcode project.
Reference: https://developer.apple.com/library/archive/documentation/MacOSX/Conceptual/BPFrameworks/Concepts/VersionInformation.html
Sylvain
armeabi is almost deprecated for android-ndk higher that r13b.
either it doesn't compile (ICE), or it executes wrongly (using long long for instance).
android people advices to use armeabi-v7a (or use r13b).
Also added native code to the Android gradle project, which allows using gradle or Android Studio to build the entire SDL application without a separate ndk-build step.
Mark Callow
README-android says to copy or link the SDL source tree to the jni folder in your Android project. It is not desirable to have to compile SDL with every application; furthermore the Android NDK has support for prebuilt libraries.
Attached is script (to be put in build-scripts) that builds the Android version of the libraries. The script builds both the existing SDL2 module and a new SDL2_main module. This is a static library containing the code from src/main/android/SDL_android_main.c. Also attached is a patch for Android.mk adding this module.
Note that when building an application's native .so using this prebuilt libSDL2main, you must use a link option, such as --whole-archive, that forces inclusion of the code in the .so because the functions in SDL_android_main are called only from Java.
According to Steam's OS stats, Windows 8.0 use is pretty much nil. Further,
Microsoft hasn't support Windows 8.0 development in any of their
actively-updated toolchains, and setting it up can be a pain.
In theory, SDL2 still supports Windows 8.0, however building of Windows 8.0
.dlls is no longer the default, if and when using the 'winrtbuild.*' scripts.
The MSVC 2012 project files for building Windows 8.0 dlls remain, though,
for the time being.
