SDL and MingW (here we go again...)

SDL Development
1

On the docs list, we get the quick feedback for the SDL wiki, and we
got this incredibly not-helpful bit of feedback recently:

Feedback from page:https://wiki.libsdl.org/Installation

Oh BTW Sam, can we have a space after that : in the template email? :wink:

Trying to figure out how to install SDL on Windows with MinGW.
Itā€™s nearly impossible, unless you
are some kind of a hacker. Why in the
world it is so complicated? Itā€™s crap!
Total and utter crap!

?I could say many things here about the above lines, but I wonā€™t.

What I will say is that setting up SDL under MingW is NOT trivial,
and indeed I never really succeeded in the endeavor 100%. I am aware
that it is far, far simpler to set up a cross-compile environment
because of MSYS issues?or that used to be true. I have no idea if it
still is. So once again, if someone who has this working can provide
some info as to what works for them, Iā€™ll be happy to actually take
another stab at it and document the resulting setup.

My understanding goes something like this:

  1. You DO NOT actually have a realistic choice of MingW32 or
    MingW-w64 at this point if you want stuff to work right. Youā€™re
    getting MingW-w64.

  2. Nutshell, get this for Win32:

http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/mingw-builds/4.9.2/threads-posix/dwarf/i686-4.9.2-release-posix-dwarf-rt_v3-rev0.7z/download

You canā€™t get SEH on Win32 (which would be best case), so the choice
of the other two is fairly arbitrary. The crowd seems to be
preferring dwarf. Also went with POSIX threads for the same reason.
If you have good arguments for other choices, reply and say so. :slight_smile:

This step is skippable if you have no desire to ever build for Win32.

  1. If you have Win64, also get this:

http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/mingw-builds/4.9.2/threads-posix/seh/x86_64-4.9.2-release-posix-seh-rt_v3-rev0.7z/download

On Win64, SEH is the ā€œonlyā€ choice really so you can theoretically
catch exceptions from Windowsā€™ DLLs. POSIX threads chosen again, and
again if you have an argument against it, please make it. :slight_smile:

  1. Get MSYS

I cannot tell you where to get it from, what version, etc. If
someone knows of a distribution of MSYS 2 with a working hg, which is
kind of important for SDL, please tell me!

  1. Install the compiler(s) and MSYS, set up a console

It is possible to install MSYS once and change your path to choose a
gcc toolchain for 32/64 bit. If thereā€™s a more preferred way to make
building both 32 and 64 bit versions of things at the same time
easier, I donā€™t know what it is. If you do, tell me. :slight_smile:

With a few things answered (most importantly where to get a decent
MSYS setup), Iā€™ll be happy to turn those into a more genericized and
hopefully future-proof version of this that walks through setting it
all up and we can find somewhere to put it, add it to the wiki,
whatever. The key question is still MSYS.

JosephOn Tue, Dec 16, 2014 at 07:45:09AM +0000, Quick Feedback Form wrote:

2

Also, just as a note, you donā€™t really need hg working in your MSYS
environment, just as long as it works on the native level (and hg supports
all mainstream OSes, last I checked).On Sat, Dec 20, 2014 at 1:47 AM, Jonas Kulla wrote:

2014-12-20 7:08 GMT+01:00 T. Joseph Carter :

You canā€™t get SEH on Win32 (which would be best case), so the choice of
the other two is fairly arbitrary. The crowd seems to be preferring
dwarf. Also went with POSIX threads for the same reason. If you have good
arguments for other choices, reply and say so. :slight_smile:

This step is skippable if you have no desire to ever build for Win32.

The choice isnā€™t entirely arbitrary - sjlj still incurs a runtime hit of
about 10 - 20% in exception heavy code.
With dwarf you donā€™t have the runtime cost, at the expense of more bloated
object code.

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

3

2014-12-20 7:08 GMT+01:00 T. Joseph Carter :

You canā€™t get SEH on Win32 (which would be best case), so the choice of
the other two is fairly arbitrary. The crowd seems to be preferring
dwarf. Also went with POSIX threads for the same reason. If you have good
arguments for other choices, reply and say so. :slight_smile:

This step is skippable if you have no desire to ever build for Win32.

The choice isnā€™t entirely arbitrary - sjlj still incurs a runtime hit of
about 10 - 20% in exception heavy code.
With dwarf you donā€™t have the runtime cost, at the expense of more bloated
object code.

4

When I last tried it, MSYS2 was in a pretty seriously ā€œnot doneā€ state and you pretty much didnā€™t have packages or a package manager yet. You basically wound up with some userā€™s snapshot of everything they cared to make work (with things like Python not necessarily working for anyone else in the resulting directory when unpacked on YOUR system.) This was around the time of the SDL 2.0 release, mind you.

Okay, that resolved which compiler(s) to get, which MSYS, and if MSYS2 is actually using pacman, it even resolved which Python. That just leaves which console alternative (Iā€™ll figure that one out, thereā€™s only a couple choices and they do coexist well for testing), and tips for building both 32 and 64 bit versions.

AFAIK, you donā€™t get anything like gcc-select on Windows, so itā€™s either full name to gcc or path tricks or both.

That just leaves a good way to build multi arch. My understanding is that Windows doesnā€™t do it like Linux, and nobody else does it like Apple. If anyoneā€™s got tips for a fairly generic build process for both, Iā€™m all ears. For SDLā€™s CMake users (both of you! :wink: ), CMake already kinda prefers to build outside the source dir, so itā€™s just a matter of doing the deed in build_ia32 and build_x64 (and maybe ARM?) with the requisite tool chain in sequence. Thatā€™s an easy script to write. Something similar is trivial for full automakemecrazy setups. Autoconf with DIY makefiles MAY work depending on how many stupid assumptions the Makefile author made. :wink: no truly universal solution can exist here, but if I can make the CMake and ā€¦/configure solutions work for the 90% of stuff it should work, I think Iā€™ll call it complete pending someone else contributing better ideas.

NOW, if I go and test and write up this thing, whoā€™s willing to host it? Ideally Iā€™d like to shove it into the SDL wiki since that means it wonā€™t go away and more people have access to maintain it if something changes like ? the maturation of clang for Windows, integration of IDEs that arenā€™t bash and vim for you lazy C++ weenies ( :wink: ), etc.

Not to mention that putting it in the wiki gives us a path to and category for more newbie dev handholding sort of documentation. I could see a similar guide for iOS being useful in the future, for example.

JosephSent via mobile

On Dec 23, 2014, at 02:26, mr_tawan <mr_tawan at hotmail.com> wrote:

AFAIK hg is just a set of python script. As long as you have python running in your MSYS environment, it should run without problems. I think you could also install mercurial separately from MSYS and update your PATH environment variable.

FYI: Iā€™m using MSYS2 (with Mingw64 suite) in my main setup. I think it much more easier to manage as it has much better package management (pacman from Arch Linux). Mercurial is available in MSYS2.

MrOzBarry wrote:
Also, just as a note, you donā€™t really need hg working in your MSYS environment, just as long as it works on the native level (and hg supports all mainstream OSes, last I checked).

On Sat, Dec 20, 2014 at 1:47 AM, Jonas Kulla <> wrote:

Quote:
2014-12-20 7:08 GMT+01:00 T. Joseph Carter <>:

Quote:
You canā€™t get SEH on Win32 (which would be best case), so the choice of the other two is fairly arbitrary. The crowd seems to be preferring dwarf. Also went with POSIX threads for the same reason. If you have good arguments for other choices, reply and say so.

This step is skippable if you have no desire to ever build for Win32.

The choice isnā€™t entirely arbitrary - sjlj still incurs a runtime hit of about 10 - 20% in exception heavy code.

With dwarf you donā€™t have the runtime cost, at the expense of more bloated object code.

SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

5

MSYS? Is it still alive?

Five years ago I remembered what niche MSYS filled. Ten years ago I even
used it.

Today - what is the point? All that time wasted on setting it up is worth
tens of Linux VMs, maybe thousands.

Also - always build out-of-tree - makes cleanup entirely free of side
effects.

6

Just stumbled upon a (probably mostly) working solution for the
impatient trying to set up a working MingW-w64 build environment for
SDL:

https://wiki.allegro.cc/index.php?title=Building_with_msys2

Sam/Ryan, I can predict now that these instructions are NOT
sufficient with the current release mainly because I distinctly
remember issues with windres 32 and 64 bit on 2.0.3? If thatā€™s still
hardcoded, can we fix that before 2.0.4? By the time Iā€™m ready for
this thing to be published somewhere, I want it to work with whatā€™s
out there.

The problem is that the program is always called windres.exe, and
whichever one is in your path is the one thatā€™ll get used. My
solution, if I got to fix it upstream, would be:

/mingw32/i686-w64-mingw32-windres.exe
/mingw32/windres.exe
/mingw64/x86_64-w64-mingw32-windres.exe
/mingw64/windres.exe

Put both in your path so that the one you prefer to default to is
first and provides plain gcc.exe and windres.exe (and friends?)
Treat the other as a cross build where your compiler, linker, etc get
specified by their full architecture name.

In fact, I propose that I will file a bug upstream to make that
change in a future package version and shove this email into the bug
report as justification. MSYS2 supports native NTFS symlinks.
Copying files is also a possibility, but one must beware of upgrades
in that case.

Otherwise, MingW-w64 just got a helluva lot simpler to set up. And
yes, it supports hg too, I just tested it! But I gotta leave it
there for now. :slight_smile:

Merry Christmas SDL list!

JosephOn Wed, Dec 24, 2014 at 11:55:19AM -0800, T. Joseph Carter wrote:

When I last tried it, MSYS2 was in a pretty seriously ā€œnot doneā€ state and you pretty much didnā€™t have packages or a package manager yet. You basically wound up with some userā€™s snapshot of everything they cared to make work (with things like Python not necessarily working for anyone else in the resulting directory when unpacked on YOUR system.) This was around the time of the SDL 2.0 release, mind you.

Okay, that resolved which compiler(s) to get, which MSYS, and if MSYS2 is actually using pacman, it even resolved which Python. That just leaves which console alternative (Iā€™ll figure that one out, thereā€™s only a couple choices and they do coexist well for testing), and tips for building both 32 and 64 bit versions.

AFAIK, you donā€™t get anything like gcc-select on Windows, so itā€™s either full name to gcc or path tricks or both.

That just leaves a good way to build multi arch. My understanding is that Windows doesnā€™t do it like Linux, and nobody else does it like Apple. If anyoneā€™s got tips for a fairly generic build process for both, Iā€™m all ears. For SDLā€™s CMake users (both of you! :wink: ), CMake already kinda prefers to build outside the source dir, so itā€™s just a matter of doing the deed in build_ia32 and build_x64 (and maybe ARM?) with the requisite tool chain in sequence. Thatā€™s an easy script to write. Something similar is trivial for full automakemecrazy setups. Autoconf with DIY makefiles MAY work depending on how many stupid assumptions the Makefile author made. :wink: no truly universal solution can exist here, but if I can make the CMake and ā€¦/configure solutions work for the 90% of stuff it should work, I think Iā€™ll call it complete pending someone else contributing better ideas.

NOW, if I go and test and write up this thing, whoā€™s willing to host it? Ideally Iā€™d like to shove it into the SDL wiki since that means it wonā€™t go away and more people have access to maintain it if something changes like ? the maturation of clang for Windows, integration of IDEs that arenā€™t bash and vim for you lazy C++ weenies ( :wink: ), etc.

Not to mention that putting it in the wiki gives us a path to and category for more newbie dev handholding sort of documentation. I could see a similar guide for iOS being useful in the future, for example.

Joseph
Sent via mobile

On Dec 23, 2014, at 02:26, mr_tawan <mr_tawan at hotmail.com> wrote:

AFAIK hg is just a set of python script. As long as you have python running in your MSYS environment, it should run without problems. I think you could also install mercurial separately from MSYS and update your PATH environment variable.

FYI: Iā€™m using MSYS2 (with Mingw64 suite) in my main setup. I think it much more easier to manage as it has much better package management (pacman from Arch Linux). Mercurial is available in MSYS2.

MrOzBarry wrote:
Also, just as a note, you donā€™t really need hg working in your MSYS environment, just as long as it works on the native level (and hg supports all mainstream OSes, last I checked).

On Sat, Dec 20, 2014 at 1:47 AM, Jonas Kulla <> wrote:

Quote:
2014-12-20 7:08 GMT+01:00 T. Joseph Carter <>:

Quote:
You canā€™t get SEH on Win32 (which would be best case), so the choice of the other two is fairly arbitrary. The crowd seems to be preferring dwarf. Also went with POSIX threads for the same reason. If you have good arguments for other choices, reply and say so.

This step is skippable if you have no desire to ever build for Win32.

The choice isnā€™t entirely arbitrary - sjlj still incurs a runtime hit of about 10 - 20% in exception heavy code.

With dwarf you donā€™t have the runtime cost, at the expense of more bloated object code.

SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

7

The point of MSYS(2) is that the most effective cross-platform build
tool ever written for gcc-alike compilers is still autoconf,
automake, libtool, and pkg-config. Like it or not, they ā€œworkā€ (as
well as they ever work) everywhere, EXCEPT WINDOWS. And like it or
not, nobody has really produced a good and functional alternative
that can really claim to do the same thing.

CMake promised that, and it might have delivered if it hadnā€™t tried
to basically be XSLT for build systems, with lots of obsolete docs on
their own web pages for supported but niche features, oh, and that
they didnā€™t grab onto the idea of pkg-config and get with that toolā€™s
devs to turn their config file format into a toolchain-agnostic
resource so that complex build scripts werenā€™t needed.

I realize Iā€™m going off on a bit of a rant here, but think about it?
SDLā€™s build system is too complex for automake because it handles
some unusual stuff when youā€™re not doing Linux builds. Plus, I think
Sam despises automake with a burning passion hotter than an emacs vs.
vi flamewar. But thatā€™s likely only because of all the ridiculous
things automake has to do in order to work everywhere.

Still, letā€™s look at SDLā€™s configure.in, shall we?

  • A hack to try and preserve user requests for build options
  • Setting build version
  • Configuring libtool
  • Figuring out host/target for cross-compiling
  • Figuring out what the installed build system is
  • A hack for a UNIX tool too dumb to handle Windows paths on Windows
  • Check for Mercurial so you donā€™t destroy the official autoconf setup.
  • A hack because autoconf might be running under cygwin to bypass using it
  • A CFLAG override mechanism
  • Hack to find system files like X11 because thereā€™s no standard here
  • Setting toolchain environment based on what we know so far
  • Hack for x64 Linux dists that use lib and lib64 rather than lib and lib32
  • A function to find a library (because this isnā€™t automake)
  • Checks for compiler options (canā€™t divine them anywhere)
  • Option for debug/assertion level
  • Check for toolchain dependency tracking for make
  • Check for linker flag support
  • A test for libc
  • A test for a gcc feature
  • Definition of what files to build (rare for a configure, but okay?)
  • Optional features with their default settings
  • Override for OSS on OpenBSD, how to do PulseAudio on Solaris properly, etc?
  • Check for Wayland
  • Check for Mir
  • A comment questioning how to link Mir on BSD and OS X
  • Check for NaCl
  • Complex check for X11 because autoconfā€™s own still canā€™t always find it, let alone its various libs
  • Hacks for two OSesā€™ locations for X11 libs by hand
  • A custom check for the Raspberry Piā€™s(? I think anyway) EGL video driver
  • Checks for other video driver support (OS X, Haiku, etc)
  • Checks for OpenGL, OpenGL ES, a random sound driver which seems to be in an odd spot in the config, etc
  • Checks for dbus, Linux events, udev, etc
  • A long list of OS-specific options for how to do pthreads (how p are they again?)
  • Test for Windows and specific checks for its build system and libs
  • Test for dlfcn and how to use it
  • Test for BSD USB driver
  • Test for how to do precise timing
  • Test for Linux version availability
  • Option to disable RPATH on systems that use it
  • A whole bunch of system-specific configuration options
  • A whole bunch of SDL buildsystem-internal regex line noise
  • Writing files
  • Telling the user what we did

More or less.

If you had something like CMakeā€™s compiler definition files included
with gcc, clang, llvm, and their like in a common format, along with
the rest of the toolchain, thatā€™d be a lot. Get support for that
into autoconf alone and rest assured that people WOULD start using
them in other build systems because theyā€™d support just about
everything but the odd Microsoft compiler or the occasional non-gcc
UNIX compiler from Oracle, Intel, or HP that donā€™t see much use
anymore. And anyone who DID use them would quickly produce shims for
them because itā€™d make them instantly work with all of those build
systems!

Develop a standardized pkgconf format that is platform-agnostic and a
means to know how to register it with the system, with the existing
pkgconf as a reference implementation and watch it become even more
widely used than it already is. In fact, if you extend the idea to
support registering more than just how to compile and link a library
and youā€™ve got gold.

A way to find X11 (provided by whatever installed it for you), its
headers and libs in general, and also the specific header or lib for
a given X extension? Or OpenGL with a vendor string (Mesa, NVidia,
Apple, etc), where the libraries and headers are, specifics for
things like cg or cuda as well as glX, wgl, and other system glue.
Oh, and a thing to query for the kinds of glue available in
preference order. (The Mac has a few options, for example?) Another
nice subsystem to standardize would be audio since there are many
options and they now emulate one another pretty frequently.

Iā€™m oversimplifying it a little I know, but not as much as Iā€™ll be
said to be doing.

JosephOn Thu, Dec 25, 2014 at 03:20:14AM +0400, Alexander Sabourenkov wrote:

MSYS? Is it still alive?

Five years ago I remembered what niche MSYS filled. Ten years ago I even
used it.

Today - what is the point? All that time wasted on setting it up is worth
tens of Linux VMs, maybe thousands.

Also - always build out-of-tree - makes cleanup entirely free of side
effects.

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

8

Hi; Guess I am one of the defacto MSYS2 people. It works but wow; serious challenge.
Total time to get everything working; 9 days and 10 reinstalls.
However there is a pile of 32 bit code still out there. For example ATM I donā€™t have a w64 version on MMAP. So no 64 bit interprocess memory.

9

Iā€™ve always used codeblocks with mingw on MS Windows
and followed lazyfooā€™s instructions for installing sdl2
never had a problem

https://lazyfoo.net/tutorials/SDL/01_hello_SDL/index.php

1 Like
10

I have it working well now. Very happy.