Beginner Question: MingwSupport

Hi friends!
I’ve got question about Mingw support for current version of OpenFL/LIME.

Demos built with MSVC2010 works.
Mingw targets passes compilation, but crashes after execution (without debug info there are messages about badly allocated ALcontext and shader problems; when debugging in gdb with debug info, gdb crashes). Legacy compilation works with Mingw, though. Is Mingw compatibility broken with non-legacy lime, and if yes - will it stays that way, or is it just temporary problem?

legacy compilation works just with static linkage of libgcc and libstdc++, with dynamic linkage excutables crashes.

with MinGW from, v 4.8.2, openfl-samples after compiling shows in console:

AL lib: (EE) MMDevApiOpenPlayback: Device init failed: 0x80004005

and then plenty of:

Shader.hx:244: Could not compile the shader:
	Fragment shader failed to compile with the following errors:
ERROR: 0:1: error(#132) Syntax error: "°<" parse error
ERROR: error(#273) 1 compilation errors.  No code generated

I’ve compiled with and without “-DUNICODE -D_UNICODE”.

When compiling with legacy mode, Heroku Shaders shows just 1st shader, then black screen (app is running, I put trace into code and it is still printing with black screen).
I tested openfl/lime 3.5.3/2.8.2, 3.4.0/2.7.0, 3.3.0/2.5.3 and got the same results.

Best Regards, Ret

1 Like

Would you mind trying the Lime “HelloWorld” and “SimpleImage” samples, and see if either works?

With Mingw 4.8.2 and recent ver. of lime nonlegacy HelloWorld got

AL lib: (EE) MMDevApiOpenPlayback: Device init failed: 0x80004005
Main.hx:15: Hello World

and green color inside window, but app did’t crash.

SimpleImage also had just AL lib error, without any Shader.hx entries. App window were instantiated and app crashed.

I’ve made other tests as well. Mingw 4.9.2 from QTcreator installer don’t work at all with shared gcc libs. In edit1 I made mistake because of this. I got 3 more Mingw’s so I will check them also.

Would you mind trying SimpleImage again, with --window-hardware=false?

Mingw4.8.2 ; I ran “lime build windows -Dmingw --window-hardware=false” and got the same results. Maybe I should put this flag in some xml file?


Mingw 4.8.2 works with Haxe 3.2.0, openfl 3.3.0 and lime 2.5.3.


With Haxe 3.2.0, lime 2.6.1 lime-examples 2.6.0 and hxcpp 3.2.205 Mingw 4.8.2 works.
With lime 2.6.2 it crashes with AL lib device init failed error. Is there a possibility to download dev of lime 2.6.1 and 2.6.2? I found just latest dev version sources on github.
And what have changed between those versions? SDL_mixer was changed to OpenAl and Native File Dialog was added I suppose.
On the other hand NME 5.5.7 and its examples also works. Is Openfl fully compatible with NME with remap?

Thanks, Ret

Problem with AL lib from Lime 2.6.2 upwards is in project/audio/openal/OpenAlBindings.cpp, in

lime_alc_open_device (HxString devicename) {
ALCdevice* alcDevice = alcOpenDevice (devicename.__s);

function. There lacks the test wheter devicename is null, and pass devicename or null.
When creating application, HxString has the null value (from lime/audio/openal/ALC.hx) :

public static function openDevice (deviceName:String = null):ALDevice {
        #if ((cpp || neko || nodejs) && lime_openal)
        var handle:Float = lime_alc_open_device (deviceName);

but on cpp it is actually HxString class, which misses the comparison operator (and I dont know how to add there such test becouse of that, not a good c++ programmer unfortuantely), and basically it cannot be null itself (msvc passes somheow through that?!).
One option is adding test and invoke

alcOpenDevice (0)
alcOpenDevice (devicename.__s)

which will add Mingw support without braking msvc compatibility;
Other option is to manually change ALC.hx,

public static function openDevice (deviceName:String = null):ALDevice {


public static function openDevice (deviceName:String = ""):ALDevice {

for mingw builds, but could break compatibility for other targets.
Unfortunately apps are still crashing after instantiate window.

My bad; Mingw is creating garbage strings from deviceName:String = null, this is why it fails with create device;

It came out that in switching from cffi to cffi prime every string that is passed into lime.ndll with Mingw build is in fact garbage data; I’ve compiled lime with msvc2010 and application with Mingw. Lime 2.8.1 works, but Lime 2.8.2 and further does not. And this is the reason of initialising wrong device in OpenAL, and other errors that made app crashing (not being able to open manifest file, bad app title, etc).

Problem was difference in HxString class representation between gcc and msvc, so without lime mingw rebuilding it is unresolvable.
I changed Lime source and was able to compile Heroku shaders with MinGW 4.8.2 from Qt online installer, since other versions lacks shobjidl.h needed by native file dialog lib.

One thing I noticed is shaders are running little faster, but will check BunnyTest if there is a difference between Mingw and MSVC.

Compiling for 64 bits should be also doable with a little effort (hxcpp got 64bit libs, recompiling lime should do the work).
And there is also a possibility of speeding up SDL/OpenGL with sse (I don’t know if it is present in msvc builds?), will check this.
Preparing patch for mingw shouldn’t break compatibility with other builds, so I could do this (difference is 99% in headers).

Do you think this would help?

1 Like

Yes, this is actually one of the errors (I mean that it was one of the fixes:)).
I was able to compile for 64 bit with Mingw, but 32 bit builds got error in crt files probably (debugger shows SIGSEGV in _pei386_runtime_relocator, so it’s error with recent 32 bit Mingw distributions, I think.
Here are Heroku Shaders for 64bit Win to test:

Got few errors still which I don’t know how to solve yet - with replacingVistaIcon for 64 bit build, if icon file is not present in bin folder, Lime throws errors and don’t run replacing icon part, but generated ApplicationMain works.
I was able to do a switch for 64 bit builds on Win with -64 flag (two small edits WindowsPlatform.hx and FileHelper.Hx). Will reformat my changes in source and eventually write a topic about it (from the other hand Mingw users are probably less then one percent here :confused: ).

Are there any 64bit ndll for Windows from Lime, or the 32bit just works for 64bit compilation?

No, currently You have to change lime source code, rebuild lime.ndll and Your app.
Quick adding 64bit support (I compiled with mingw, so don’t know if this will work with MSVC):

  1. You have to set up Your compiler correctly in hxcpp probably (I’m using mingw, so it is just setting up MINGW_ROOT)

in development version of lime:
in file tools/platform/WindowsPlatform.hx change
in line 136:

flags.push ("-DHXCPP_M32");


			var is32 = true;
			for(str in targetFlags.keys()){
				if(str == "64"){
					is32 = false;
				flags.push ("-DHXCPP_M32");
			} else {
				flags.push ("-DHXCPP_M64");

in file tools/helpers/FileHelper.hx add in function “public static function copyLibrary” in line 231:

        if( == Platform.WINDOWS){
            for(str in project.targetFlags.keys()){
                if(str == "64"){
                    directoryName += "64";
  1. In file project/src/backend/sdl/SDLWindow.cpp change in line 111:
::SetClassLong (hwnd, GCL_HICON, reinterpret_cast<LONG>(icon));


                #ifdef HXCPP_M64
                ::SetClassLong (hwnd, GCLP_HICON, reinterpret_cast<long long>(icon));
                ::SetClassLong (hwnd, GCL_HICON, reinterpret_cast<LONG>(icon));

and in /src/include/system/System.h comment lines 102 - 104:

//#ifndef _MSC_VER // [     
//#error "Use this header only with Microsoft Visual C++ compilers!"
//#endif // _MSC_VER ] folder /tools run command "haxe tools.hxml"
6. try rebuilding of lime with command
lime rebuild windows -64 -DHXCPP_M64
(if You compiling with MINGW, add -Dmingw also, but there will be plenty of code fixes :confused:)
7. Fix eventual errors and optionally warnings in source code and rebuild.
8 compile your app with:
lime build windows -64 (openfl build windows -64 should work either).
(again, with MINGW add -Dmingw also)
9. Build script will fail if there aren’t lime.ndll in 32 bit version in folder ndll/Windows/ (even for 64 bit builds, becouse SVG creation script needs 32 bit version. I don’t know yet is there a chance to swap lime into 64 bit here and build apps without error just with 64 bit lime. Probably neko should be rebuilt also :confused: ).

Ok, I am gonna try this & test 64bit build, but I am stuck with shader problem you got as well.

Your OS is linux (crosscompilation) or Win with mingw?

Linux doing cross-compilation.

My tests showed that 32bit mingw version dont work even after lime recompilation and linking. If You read the whole topic - 32 bit versions get runtime error in _pei386_runtime_relocator function (I tested on Win with various flavors of Mingw, and it seems that only version 4.8.2 from qt actually works).
BTW - if You are compiling for example pirate pig with mingw on linux, do You also have MacroShader error? I tried to build Pirate Pig on linux targeting linux and have this error, but didn’t check whether windows target from linux will also have it.

I have not tested QT yet, what I tested before on different Linux systems was the one that were available from its respective repositories. Mingw 4.9.2 both i686 and x86_64 produce a working Windows Exe for Windows 7, Windows 10 and even Wine :slight_smile:

Well done:)
Lime versions newer than 2.6.1 also works? I’ve got kubuntu 14 and win 7, but didn’t tested it yet with linux crosscompiler

Yes, cross-compilation works, but only for fixed Lime 2.6.x. Now, I could not make it work for Lime 2.7.x due to the shader problem.

Well, fixed is other than official dev from github?

Yes, to enable cross-compilation, you got to fix some lines on


        if (project.targetFlags.exists ("neko") || != PlatformHelper.hostPlatform) {
            targetType = "neko";


        if (project.targetFlags.exists ("neko")) {
            targetType = "neko";
        } else if ( != PlatformHelper.hostPlatform && PlatformHelper.hostPlatform != Platform.LINUX){

            targetType = "neko";


Then do:

haxelib run lime rebuild tools

you could be able to compile your app through

haxelib run openfl build windows -32

by the way, dont forget to copy some dll files from AppName/Export/windows/cpp/obj to your AppName/Export/windows/cpp/obj directory.