I’ve been hacking on a little collection of software-rendered graphics
toys in a program called rototiller, which you can find here .
Recently I added an SDL rendering backend as a means of adding support
for Windows, building on GNU/Linux via mingw32.
I use automake for the build system, and have utilized the sdl2.m4
macros bundled in the SDL2-2.0.7 source.
Since I’m cross-compiling with mingw32, I’ve been taking advantage of
the --host= and --with-sdl-prefix= flags in my configure line.
However, this is producing dynamically linked binaries which require
SDL2 be installed on the Windows host running the program, something
I’d rather not require.
To work around this I’ve been manually linking statically by
extracting the linker line from
make V=1, and augmenting it with the
sdl2-config --static-libs and an additional
It’s preferable to have this more streamlined into the automake build
process. It’s unclear to me what the ‘correct’ way to do this would
be. I see no mention of
--static-libs in the sdl2.m4, but there
does seem to be a normal pkg-config .pc file installed in the SDL2
cross-tools installation. So perhaps it’s preferable to actually
cease using the provided sdl2.m4 and instead use the standard
PKG_CHECK_MODULES macro in my configure.ac and
PKG_CONFIG_PATH set to the cross-tools SDL2 installation?
I also have another complication in that the
output includes -mwindows, when my application is actually a console
application with a stdio-based UI which also does graphics.
For my program to function properly on Windows I need to
s/-mwindows/-mwin32/ otherwise the console gets detached by the OS at
It seems erroneous for SDL2 to be specifying -mwindows in the libs
flags. We only want the linker flags for the dependencies - it
shouldn’t have an opinion on the type of application we’re building.
These seem like issues someone else must have already encountered,
since I’m not doing anything particularly special here. Any advice