Discussion: Windows MKXP

[hanetzer]

been fiddling with building mkxp on windows, after catching a stray uint and trying again, it seems the main issue regarding building on windows is a gmtime_r conflict that occurs upon inclusion of ruby's win32.h

The exact error generated can be found in this gist:
https://gist.github.com/ntzrmtthihu777/e81aaa9cd95277bf9991#file-gistfile1-txt
Note: compiled with clang/clang++ for more verbose error output.

[hanetzer]

found the smallest test program one could write to trigger this output,

#include <string>
#include "ruby.h"
int main() {
  return(0)
}

compiling with g++ test.cpp -Iruby-2.1.0/ -Iruby-2.1.0/x64-mingw32/ results in the above error

[cremno]

Could you try compiling with -std=c++98? Maybe there is a reason why this isn't explicitly set. AFAIK mkxp itself doesn't use any GNU extensions.
But even if mkxp compiles fine with this workaround, CRuby's header shouldn't unconditionally declare gmtime_r.

[hanetzer]

ok, will give it a shot and report back. Note, reversing the #incldue directives fixes the issue in the test.cpp program, but its probably too minimal for application in mkxp itself.

[hanetzer]

Nope, same error as before... this is rather annoying, windows, y u no posix!?

[hanetzer]

I don't suppose you have access to a windows machine to test with? this is really irksome :/

[Ancurio]

This is yours yes? https://www.ruby-forum.com/topic/4939821

Also this could be related: Also this could be related: http://sourceforge.net/p/mingw/bugs/1625/ (also this)

[hanetzer]

Yes, that is mine, and I've seen both of those pages, lol. gmtime_r is defined in pthreads.h and time.h in the msys2 package mingw-w64-{i686,x86_64}-winpthreads-git
I'm going to bug the mingw-w64 folks as well

[hanetzer]

Hmm... I've reported it to mingw-w64 and they're gonna convert gmtime_r to an inline from a macro, but my ruby bug report has been updated with including <ctime> as fixing the test program.

[hanetzer]

Yep, the patch fixes the gmtime_r issue but raises a new one.

[Ancurio]

What new issue?

[hanetzer]

rand(), but including <stdlib.h> in pthread.h fixes that, now I just have to fix up this sdl_sound issue :p

[hanetzer]

Now the current issue is:
https://gist.github.com/ntzrmtthihu777/3b754e8aea64ad73141f
a whole bunch of undefined reference to ModPlug_* basically.

[Ancurio]

Oh, you're statically linking. Yeah, the problem is very likely my limited pkgconfig file for SDL_sound which doesn't pass on the correct linker flags in case of static linking. You could compile SDL_sound with only WAV support as a temporary workaround for now, or compile it into a dll instead.

[Ancurio]

Alternatively, since all this needs is a -lmodplug, you could either add that manually in the Makefile, or try adding the line Requires.private: libmodplug to your SDL_sound.pc.

[hanetzer]

yeah. I don't really want to link static, but I can't seem to get sdl_sound's hg version with the patch to compile into a shared library; its driving me crazy, lol.