Forums » StepMania Development » MinGW porting notes

1
**Go check out the wiki. This shit is old and wrong.**


IT'S WORKING! There's still a hell of a lot to do (in particular I'll bet good money the crash handler is completely hosed) but things are working well enough that you can play!

If you want to join in on the fun:
1) Download mingw-w64 from mingw-builds and extract it someplace
2) Download msys from mingw-builds and extract it to your shiny new mingw64 folder
3) run msys. You'll get a bash shell.
4) hg pull https://roothorick@code.google.com/p/stepmania/ -u mingw
5) cd stepmania; sh autogen.sh && ./configure && make
6) Your shiny new stepmania.exe is buried in the src/ directory.

My old notes rest below, detailing some of the problems I ran into, and occasionally how I fixed them. If you want specifics please do ask, I love talking about myself.

Why NOT make these public amirite

The "mingw" branch in HG has all my progress so far. It configures, it compiles, it links, and if you shuffle DLLs around, it runs long enough to dick around in ThemeManager for a little bit before mysteriously dying.

From stepping through it... it seems to be dying in the foreach loop at ThemeManager.cpp:434. I'm gonna have to take a good long look at FOREACHS_CONST to try to figure out what happened here.

P.S. GDB is showing a number of threads spawning with stacks all riding up in the 0x76xxxxxx-0x77xxxxxx range and no debugging symbols. I'm 99% sure these are being spawned by Windows/Microsoft DLLs in response to some event API and can be safely ignored.

Everything's all hunky-dory until it hits a metric of the Grade type. Then things explode.

Here's the full backtrace:

#0 RageException::Throw (
sFmt=0x9ef3f5 <g_fSimultaneousThreshold+449> "[Lua panic] %s")
at RageException.cpp:61
#1 0x006dce58 in LuaPanic (L=0x99fc640) at LuaManager.cpp:225
#2 0x006260e6 in luaD_throw (L=0x99fc640, errcode=2)
at ../extern/lua-5.1/src/ldo.c:104
#3 0x00625e93 in luaG_errormsg (L=0x99fc640)
at ../extern/lua-5.1/src/ldebug.c:609
#4 0x0061dfa4 in lua_error (L=0x99fc640) at ../extern/lua-5.1/src/lapi.c:960
#5 0x004fbad5 in CheckEnum (L=0x99fc640, table=..., iPos=1, iInvalid=22,
szType=0x9b79a2 <_ZL29NUM_USER_GAME_TO_DEVICE_SLOTS+46> "Grade",
bAllowInvalid=true) at EnumHelper.cpp:46
#6 0x0050faa3 in Enum::Check<Grade> (L=0x99fc640, iPos=-1,
bAllowInvalid=true) at EnumHelper.h:46
#7 0x0050f725 in LuaHelpers::FromStack<Grade> (L=0x99fc640,
Object=@0xb70150: Grade_Tier01, iOffset=-1) at Grade.cpp:9
#8 0x007a2e67 in ThemeMetric<Grade>::Read (
this=0xb7013c <GRADE_TIER_FOR_EXTRA_1>) at ThemeMetric.h:101
#9 0x0070598c in ThemeManager::ReloadSubscribers (this=0x9da8f98)
at ThemeManager.cpp:435
#10 0x0070591a in ThemeManager::SwitchThemeAndLanguage (this=0x9da8f98,
sThemeName_=..., sLanguage_=..., bPseudoLocalize=false,
bForceThemeReload=false) at ThemeManager.cpp:426
#11 0x00587b32 in StepMania::ChangeCurrentGame (g=0x9ed860 <g_Game_Lights>)
at StepMania.cpp:849
#12 0x00587809 in SwitchToLastPlayedGame () at StepMania.cpp:808
#13 0x00588809 in main (argc=1, argv=0x345278) at StepMania.cpp:1050


There is a LUA_USE_LINUX define that I disabled because hey, not Linux. Perhaps answers are here. The crash is definitely Lua related; it appears that the parser isn't parsing some enumerations correctly.

Logging infrastructure does get sort-of set up but nothing makes it to the logfile. I think my next step should be to force the log window open and see what secrets it can share with me.

Also I should inspect RageException for platform-specific stuff.

Last edited: 9 November 2013 8:30pm

Reply
I don't remember exactly what fixed it but I got past the lua issue.

It's now bombing out, possibly a stack overflow. It seems to kick off at LoadingWindow_Win32.cpp:33. hWnd is 0x0, and r seems to have some bogus values here. r is probably an output to be written to as the address is passed, which means hWnd is probably bogus too.

This problem occurs because we're not checking that CreateDialog doesn't fail (return null). See LoadingWindow_Win32.cpp:148 however, CreateDialog failing is a problem in itself! Why is that happening?

The problem was that we weren't pulling in WindowsResources.rc. And then I ran into an issue where MinGW doesn't have winres.h. It turns out that atlres.h is an acceptable substitute.

Then I had issues with libpng segfaulting. This was caused by a zlib version mismatch between that packaged in mingw-builds mingw64 and my pack-in. I just ditched my pack-in and rebuilt libpng. And now it works!

Last edited: 29 October 2013 10:30pm

Reply