Compiling SDL2 in MSYS2 with sound?

[backwardsEric]

There's a modified version of src/main.c at https://github.com/backwardsEric/ang...ing/src/main.c which avoids the compiler warning about the missing prototype for SDL_main(). I'd be interested to know that the resulting executable from compiling it under MSYS2 starts up as expected on Windows. If it does, it might also be worth checking if there's any impact on https://github.com/angband/angband/issues/5497 (MSYS2 compiled SDL2 front end blanks out after a Windows lock screen) and https://github.com/angband/angband/issues/5512 (MSYS2 compiled SDL2 front end doesn't deal well with display switches).

[smbhax]

It fixes the "missing prototype for SDL_main()" warning. : ) It doesn't fix the screen blanking stuff for MSYS2 or Cygwin/X (Cygwin/X being affected only by 5512), though.

[smbhax]

Compiling with

$ make -f Makefile.msys2.sdl2 SOUND=yes

results in a 22.1 MB angband.exe, whereas the downloadable 4.2.4 Windows front end .exe is only 1.97 MB. Compiling with

make -f Makefile.msys2

gets me a I think it was 1.68 MB GCU-only .exe. But is there a way to get a slimmer SDL2 .exe? Is the additional file size due to necessary SDL2 stuff?

(I tried lumping on parameters that cut a 200 MB+ Hengband .exe down to 4 MB, ie

$ make -f Makefile.msys2.sdl2 SOUND=yes CXXFLAGS="-g0 -O2"

after a make "clean," but the .exe size remained 22.1 MB.)

[backwardsEric]

Makefile.msys2.sdl2 is compiling with debugging symbols so that'll be part of the 22 megabytes. To avoid that, it's probably easiest to edit Makefile.msys2.sdl2 and remove "-g" from CFLAGS (it's at line 101 in the current version). For the normal Windows builds, removing the debugging symbols saved ~5 megabytes in the size of the executable.

With Makefile.msys2.sdl2, the SDL2 libraries are linked statically, which also bloats the executable size. I tried once to link those dynamically in the hopes that would simplify what libraries have to be specified in Makefile.msys2.sdl2 but had no success. So I don't have any easy pathway for you to avoid that part of the large executable size.

[smbhax]

Ah! Yeah setting -g0 there got the .exe down to 15.7 MB. Better than 22.1. : )

Removing the -static line (104) got the .exe down to 4 MB or so but then it just started complaining about missing dlls, four at a time, starting mostly with the SDL2 ones. ; )

[AnonymousHero]

Try running "strip" on the executable post-build.

[smbhax]

Originally Posted by AnonymousHero

Try running "strip" on the executable post-build.

Ooh! "strip angband.exe" gets it down to 11.5 MB, with or without setting -g0 in the Makefile. : )

[Pete Mack]

Strip is a bad choice. You won't be able to report bugs. Use -O2 optimization. It'll make a clean build. If you can find a static build of the SDL library you'll do better, too.

[smbhax]

Aw. Well, it's already got -O2 in there, at least.

[smbhax]

Not sure about the "static build of the SDL library" thing. Googling suggests static linking the SDL2 library is a little involved. These pages for instance

https://stackoverflow.com/questions/...linking-errors (2022)
https://stackoverflow.com/questions/...sdl2-libraries (2013)

which are not MSYS2-specific, mention a lot of additional linker flags, and something about special handling surrounding a "libSDL2.a" file. Well, the main 2022 answer seems to be

If you want to link SDL2 dynamically (this should be your default course of action), you need to add libSDL2.dll.a to your library directory. Then libSDL2.a will be ignored and can be removed. It should just work, no other changes are needed.

No idea if any of that applies to MSYS2 though. This stuff is a bit over my head.

There's also this page

https://stackoverflow.com/questions/...rams-correctly

which does have a section on MSYS2, titled "A saner alternative":

Install SDL2 from its package manager. Use a tool called pkg-config (also from the package manager) to automatically determine all necessary flags (pkg-config --cflags SDL2 for compiler flags, pkg-config --libs SDL2 for linker flags).

This is the same experience as you would have on Linux (maybe except for some DLL management hassle)