Build fails on Windows when unicode is enabled due to incompatible entry point name with SDL2

[kalibera]

Building fluidsynth (version 2.4.2) for Windows fails when trying to link fluidsynth.exe, SDL_main is not found (SDL2 version 2.30.11), when unicode support (UNICODE) is enabled, which is the default. I am not sure whether it is a bug of fluidsynth or sdl2, but the technical cause is as follows.

SDL_main is supposed to be the entry point in the application, so in fluidsynth.exe, but it is not. The problem is that SDL2 expects that the application would define its entry point as "main" even when building with unicode enabled (and SDL2 renames it to "SDL_main"). See the SDL.h file:

/**
 *  \file SDL_main.h
 *
 *  The application's main() function must be called with C linkage,
 *  and should be declared like this:
 *  \code
 *  #ifdef __cplusplus
 *  extern "C"
 *  #endif
 *  int main(int argc, char *argv[])
 *  {
 *  }
 *  \endcode
 */

However, fluidsynth defines the entry point as "wmain", so it won't be renamed to SDL_main, and the symbol wouldn't be found. It is indeed not just the name of the entry point, but also the arguments - SDL2 expects that the entry point would accept narrow characters. One can build fluidsynth fine when "unicode" is disabled per cmake option "-Denable-unicode=OFF".

[derselbst]

Thanks for the report! Well, I am truly shocked. Hijacking a program's main function just because I included the SDL.h header is totally unacceptable! Also, the reason for this drastic measure isn't properly documented by SDL. Their reason to "run code before other code runs" is just the way most backdoors work. And IMO, it is a reason for completely removing SDL support, if we cannot prevent it from doing so. Esp. this is why any app is supposed to call SDL_Init() to handle the startup stuff.

I quickly looked through the SDL code. It seems that this part has undergone a few changes between SDL2 and SDL3. I will try to reproduce your finding, then I'll see if defining SDL_MAIN_HANDLED solves this problem appropriately.

[kalibera]

Thanks for looking into this. I was surprised by the "main" replacement business as well. I assume the previous version of fluidsynth worked with SDL2 because it didn't use "UNICODE" (and I am using UCRT so I assume I don't need UNICODE, so I am happy disabling that in my builds).

[derselbst]

SDL3 was just released yesterday, which no longer automatically includes SDL_main.h. Moving to SDL3 would be my preferable solution, but it requires a few code changes in fluid_sdl2.c. I'm not sure when I'll find time to do so, hence I'd welcome a PR. Until this is done, I will disable SDL2 support by default for the next fluidsynth release.

[derselbst]

Fixed by adding support for SDL3, which will be part of upcoming 2.4.4.

[kalibera]

Great, thanks.