If a program built against one version of SDL is run in an
environment where there is an earlier version of the SDL .so library
installed, the result varies depending on platform configuration; in
the best case, it won't start at all, at worst it aborts in the
middle of the user doing "something important" (systems implementing
lazy symbol resolution). verdefs on the other hand are always checked
on startup.
The dependency information present in programs and shared libraries
is not only of value to the dynamic linker, but also to a
distribution's package management. If the dynamic linker is able to
tell that a program is not runnable per the above, a package manager
is able to come to the same conclusion — and block the installation
of a nonfunctional program+library ensemble.
Because there are a lot more symbols than there are libraries (I am
going to throw in "10^4 to 1 or worse"), package managers generally
do not evaluate symbols, but only e.g. the SONAME, NEEDED and VERNEED
fields/blocks. Because the SONAME is the same between two SDL
versions like 2.0.24, and 2.0.26, everything rests on having verdefs.
This patch proposes the addition of verdefs.
When SDL is included as a subproject, the following error might appear:
```
CMake Error: Error required internal CMake variable not set, cmake may not be built correctly.
Missing variable is:
CMAKE_OBJC_COMPILE_OBJECT
```
This is probably because the master project does not see certain OBJC related variables
The internal function SDL_EGL_LoadLibrary() did not delete and remove a mostly
uninitialized data structure if loading the library first failed. A later try to
use EGL then skipped initialization and assumed it was previously successful
because the data structure now already existed. This led to at least one crash
in the internal function SDL_EGL_ChooseConfig() because a NULL pointer was
dereferenced to make a call to eglBindAPI().
Anonymous Maarten
Jan Engelhardt
Sam Lantinga
Ozkan Sezer
Wohlstand
Ryan C. Gordon
Ivan Epifanov
Philipp Wiesemann