Mingw-w64 + MSYS + SDL

I’ve asked about this a few times here and there and mostly met with
blank stares and shrugs, so I’ve sort of undertaken the process of
figuring it out. When I’ve finished the process, I’ll talk to Sam
about where to shove it on the wiki (probably as a tutorial?)

Here’s the very rough outline of what I’ve done so far:

  1. Install TDM-GCC-64. It’s in C:\TDM-GCC-64.
  2. Install TDM-GCC-32. It’s in C:\TDM-GCC-32.
  3. Install MSYS. It’s in C:\msys. I used the latest from here:
    http://sourceforge.net/projects/mingwbuilds/files/external-binary-packages/
  4. Install Console. I’ll save that for the tutorial.
  5. Create C:\msys\mingw directory.
  6. Edit C:\msys\etc\fstab to contain “C:\TDM-GCC-64 /mingw”.
  7. Create a Start menu shortcut to run bash --login -i in C:\msys.

If you have 64 bit windows and will never build a 32 bit binary ever,
you could have skipped step 2 and you’re done, subject to what
doesn’t work. :confused:

ISSUE: Need -m32 in CFLAGS/LDFLAGS to build 32 bit
ISSUE: If you’re running 32 bit, you need TDM-GCC-32’s gdb.exe.
ISSUE: SDL needs TDM-GCC-32’s windres.exe to link 32 bit.
ISSUE: dinput.h is found, but ? no XInput support.
ISSUE: The included hg is broken. Need to replace it.
ISSUE: I’ve read MSYS has a simplistic package fetcher, not here?

An alternative mingw-w64 build MIGHT solve the first 3 problems in a
more traditional --host --target manner, but TDM-GCC’s use of _64
suffixes on libs is a nice feature. Dunno if it’s possible to keep
it and fix the other issues. Someone more of a mingw expert will
have to comment, if we can find anybody.

The lack of XInput support in this build totally explains the debate
elsewhere on the list regarding SDL’s DirectInput being “broken”. As
i explained there, it was actually Microsoft’s XBox 360 controller
driver that’s broken. Ryan said that XP should have XInput, but
clearly it’s not happening on my system at least. I’ll dig more. I
may just not have installed new enough crap on my aging WinXP SP3
system?

A different MSYS setup might solve the last two issues. Certainly
you can nuke the broken hg and just install the Windows Mercurial
package.

Joseph

Message-ID: <20131023000619.GB2403 at amaya.spiritsubstance.com>
Content-Type: text/plain; charset=utf-8; format=flowed

I’ve asked about this a few times here and there and mostly met with
blank stares and shrugs, so I’ve sort of undertaken the process of
figuring it out. When I’ve finished the process, I’ll talk to Sam
about where to shove it on the wiki (probably as a tutorial?)

Here’s the very rough outline of what I’ve done so far:

ISSUE: I’ve read MSYS has a simplistic package fetcher, not here?

The MSYS project actually has two. One that I think you can use for
MSYS (aka MSYS1), another that includes a GUI interface and can be
used for MSYS2.

Beware that recently there’s a fair amount of noise on the MinGW/MSYS
list about the packages: they keep goofing on e.g. which package
provides or needs which file. In general, I suspect that they might
need to write a dedicated packaging tool (I don’t know the details of
how they’re building packages now, but I suspect that they need a
better solution). Fortunately the MSYS2 version does apparently allow
sources other than MSYS/MinGW, so while I’m not certain how well a
"sloppy" compiler package would work with the “standard” MinGW, I
assume that a well-designed package would work perfectly fine. At this
point, it’s presumably just a matter of time before all the other
projects that want to use MSYS2 wind up writing packages for their
stuff.

An alternative mingw-w64 build MIGHT solve the first 3 problems in a
more traditional --host --target manner, but TDM-GCC’s use of _64
suffixes on libs is a nice feature. Dunno if it’s possible to keep
it and fix the other issues. Someone more of a mingw expert will
have to comment, if we can find anybody.

I’m afraid that you’ll probably need to ask on the mingw-w64
mailinglist, assuming that there is one. The only thing I know for
certain is to absolutely not ask on the vanilla MinGW list, they’re
pretty thorny :slight_smile: .

The lack of XInput support in this build totally explains the debate
elsewhere on the list regarding SDL’s DirectInput being “broken”. As
i explained there, it was actually Microsoft’s XBox 360 controller
driver that’s broken. Ryan said that XP should have XInput, but
clearly it’s not happening on my system at least. I’ll dig more. I
may just not have installed new enough crap on my aging WinXP SP3
system?

Apparently you should be able to use the Microsoft SDK, though that
might prompt some license issues. Though if you try it, then I would
definitely suggest doing it in a separate install, lest files be
clobbered.> Date: Tue, 22 Oct 2013 17:06:19 -0700

From: “T. Joseph Carter”
To: SDL Development List
Subject: [SDL] mingw-w64 + MSYS + SDL

ISSUE: I’ve read MSYS has a simplistic package fetcher, not here?

The MSYS project actually has two. One that I think you can use for
MSYS (aka MSYS1), another that includes a GUI interface and can be
used for MSYS2.

Beware that recently there’s a fair amount of noise on the MinGW/MSYS
list about the packages: they keep goofing on e.g. which package
provides or needs which file. In general, I suspect that they might
need to write a dedicated packaging tool (I don’t know the details of
how they’re building packages now, but I suspect that they need a
better solution). Fortunately the MSYS2 version does apparently allow
sources other than MSYS/MinGW, so while I’m not certain how well a
"sloppy" compiler package would work with the “standard” MinGW, I
assume that a well-designed package would work perfectly fine. At this
point, it’s presumably just a matter of time before all the other
projects that want to use MSYS2 wind up writing packages for their
stuff.

I wonder why everyone always wants to reinvent the wheel for this
stuff? sigh For builds from source, Gentoo, MacPorts, and Fink
all have great build from source package managers, and those are just
the ones I have myself used enough to understand them.

For binary packages, it’s really hard to argue with dpkg and rpm and
either apt (with or without its or yum. It actually wouldn’t be
that hard to port Synaptic if you REALLY want a GUI package manager.
These may seem “overkill” for a “minimal” GNU system, but let’s face
it: There’s not much minimal about how msys gets used. It’s pretty
much cygwin done ? well, not “right” at this point, but less wrong.
Sure, you don’t get a proper POSIX system, but that’s become less and
less relevant as open source has become more mainstream.

Personally, I dunno why nobody has just taken the thin msys POSIX
layer and begun building something more modern with it. I guess
mostly because that’s a big project and anyone who wants it does so
because they have other big projects of their own to sort out.

An alternative mingw-w64 build MIGHT solve the first 3 problems in a
more traditional --host --target manner, but TDM-GCC’s use of _64
suffixes on libs is a nice feature. Dunno if it’s possible to keep
it and fix the other issues. Someone more of a mingw expert will
have to comment, if we can find anybody.

I’m afraid that you’ll probably need to ask on the mingw-w64
mailinglist, assuming that there is one. The only thing I know for
certain is to absolutely not ask on the vanilla MinGW list, they’re
pretty thorny :slight_smile: .

That’s the whole reason I want to stay well away from mingw32 in its
entirety. For the moment, I have mingw-w64 sorted well enough for
the moment by installing windres and gdb from TDM-GCC-32 as _32.exe,
moving the TDM-GCC-64 versions to _64.exe, and putting the one I want
to use as just .exe ? Not perfect, but it will work for the moment.

The lack of XInput support in this build totally explains the debate
elsewhere on the list regarding SDL’s DirectInput being “broken”. As
i explained there, it was actually Microsoft’s XBox 360 controller
driver that’s broken. Ryan said that XP should have XInput, but
clearly it’s not happening on my system at least. I’ll dig more. I
may just not have installed new enough crap on my aging WinXP SP3
system?

Apparently you should be able to use the Microsoft SDK, though that
might prompt some license issues. Though if you try it, then I would
definitely suggest doing it in a separate install, lest files be
clobbered.

I missed it before, but the xinput.h header IS there. I dunno why
SDL isn’t using it. I’ll have to go back and have a look to see if I
can find some reason to explain it.

I’m at the stage where everything I see for my XBox 360 controller
says it is a DirectInput device?y’know with triggers combined into a
ridiculous approximation of a Z axis. I cannot seem to get SDL to
see it differently. I don’t know what can, if anything. Or if XP is
just broken in this regard.

JosephOn Tue, Oct 22, 2013 at 10:54:57PM -0500, Jared Maddox wrote:

2013/10/23, T. Joseph Carter :

I missed it before, but the xinput.h header IS there. I dunno why
SDL isn’t using it. I’ll have to go back and have a look to see if I
can find some reason to explain it.

Actually, I think the header is there but the required library is
not, though I need to recheck to make sure. But yeah, I think the
XInput implementation is not complete and probably not really in an
usable state for now.

According to SDL, what’s needed is there. And Ryan says that what
Windows needs is there too. I dunno.

At the moment I’m looking for some means of seeing this controller
work in Windows XP at all, SDL or not. If it cannot work in XP at
all, I’ll consider the problem to be XP and not MingW.

JosephOn Wed, Oct 23, 2013 at 10:27:19AM -0200, Sik the hedgehog wrote:

2013/10/23, T. Joseph Carter <@T_Joseph_Carter>:

I missed it before, but the xinput.h header IS there. I dunno why
SDL isn’t using it. I’ll have to go back and have a look to see if I
can find some reason to explain it.

Actually, I think the header is there but the required library is
not, though I need to recheck to make sure. But yeah, I think the
XInput implementation is not complete and probably not really in an
usable state for now.