ToME: the Tales of Maj'Eyal

The official Linux builds posted by DarkGod on te4.org currently dynamically link with a pre-2.0-release SDL2 Mercurial snapshot. Between when this snapshot was taken and the official SDL2 release, some visible function names have changed which are starting to cause issues with some Linux users.

Since SDL2 has been officially released, many major Linux distributions are now offering libsdl2 / libsdl2_image / libsdl2_ttf packages. These packages have a stable API, and this API is not 100% compatible with the API present in DarkGod's SDL2 2.0.0-beta Mercurial snapshot. If a user already has these SDL2 libraries installed by their package manager, and these libraries are found by the system before the libraries supplied by DarkGod, t-engine will choke.

I see two solutions to this problem. One is for DarkGod to statically link SDL2 with t-engine. The other is for DarkGod to update his SDL2 libraries to a stable release and do a clean rebuild of t-engine linking against the new libraries. This would let users use their system-supplied SDL2 libraries over those supplied in the t-engine distribution without an API clash.

Note that these function name changes do not require any immediate changes to the te4 code base. The old functions now exist as macros calling the new functions. Only a fresh set of SDL2 libraries/headers and a clean t-engine build are needed.

Relevant SDL2 API change for reference

> Note that these function name changes do not require any immediate changes to the te4 code base
hold on, but t-engine always required a separate sdl to build and never shipped it's own sdl headers/libs. or did it? if it did not, then why simple update of installed sdl libraries makes them incompatible(you told earlier that they provide macros wrapping for previous api version)?

It's a question of which function calls are visible in the shared object. The old pre-release libraries that DG provides in the 1.0.0->1.1.5 official releases have SDL_MutexP and SDL_MutexV exposed as functions. Newer, officially released SDL2 libraries have SDL_LockMutex and SDL_UnlockMutex functions exposed in the shared object. So, you can't just drop in a newer shared object since there is an API clash. T-Engine expects to find SDL_mutexP/mutexV functions dynamically. They are not present in the system libs, so t-engine crashes.

Now if t-engine is rebuilt against new headers, the existing t-engine SDL_mutexP/V calls would be turned into SDL_Lock/UnlockMutex function calls by the macros supplied by SDL. If new headers are not used, even if t-engine's codebase uses SDL_Lock/UnlockMutex directly, the issue is still the same! In the old headers/libs that DG uses, SDL_Lock/UnlockMutex calls were macros converted to mutexP/V function calls. There could be more instances of API conflicts like this, as there were a lot of commits between DG's libsdl2 revision and the official 2.0.0 release.

fixed thanks