Beginner Question: MingwSupport

Well, fixed is other than official dev from github?

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

haxedir/lib/lime/2,6,x/lime/tools/platforms/WindowsPlatform.hx

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

into

        if (project.targetFlags.exists ("neko")) {
            
            targetType = "neko";
            
        } else if (project.target != 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.

I did not change it, the value that appears in the toolchain is the default value of mingw_root from mingw repositories.

I’ll check that when I’ll be on Kubuntu machine, now I’m at Win7 :confused: . On linux, do You experience shader problems from version 2.7.x? Last working version is Lime 2.6.9?
BTW have You read about those?



:slightly_smiling: Maybe it could be pushed into macosx also with crosscompilation :slight_smile:

Cool, It could be pushed, but I dont have Mac to do some test. :smile:

I got the shader problem on 2.7.x, now even neko cross-compile dont work. :frowning:

Linux native build works fine though, so I dont know what have we got missing into the Mingw compile toolchain or maybe into the Lime OpenGl versions check.

On my Kubuntu I got error while compiling to linux target… :confused: Could You check this thread?

@Dominic_Guana what is Your MINGW_ROOT value in mingw-toolchain.xml for linux to windows crosscompilation?

I did not change it, the values I have are the default values of mingw_root from the mingw-toolchain.xml, I have back read the works you have done so far, and it appears that we should have a mingw compile of lime.ndll to make the app work, what might have caused this difference?

Yes, I made it work (heroku shaders from link


was compiled with mingw for 64 bit windows), there are just header and common types that should be fixed for it to work.

Cool! So aside from the change in OpenGl coding in Lime, there might also have been some changes in the Lime.ndll after 2.6 causing this issue. Can you give us a detailed information on how we could be able to fix the header and common types?

Sure, I forked lime, will give link to repo with changes tomorrow :slightly_smiling:

I forked Lime and added MinGW support here:

Great to hear that! :slightly_smiling:

Tried your patch from https://www.dropbox.com/s/fsyvfh7k1ld6ysy/mingw32_and_64bit.patch?dl=0

Now, I keep seeing the following, is it just normal?

FileHelper.hx:231: Windows
FileHelper.hx:231: Windows
FileHelper.hx:231: Windows
FileHelper.hx:231: Windows 

Ah, there is trace in lime/tools/helpers/FileHelper.hx
in function copyLibrary, somewhere near line 230

trace(directoryName);

You can remove it and rebuild tools.
There should be also added in file /lime/project/Build.xml near line 44

<compilerflag value="-DWINVER=0x0502" if="mingw"/>

I get an gl/GL.hx not found.

There are fixes for it already, but it seems that I cannot select target architecture, and apps compilation don’t work. I’ll try to fix it soon.

I am still on compiling Lime.ndll for mingw. Could I fix it manually? Or its available from your git?

It is on git, You could fix this easily though. Just replace this line in header which generates error into:

 GL/gl.h

On linux upper and lower case matters. There will be also Windows.h that needs changing into windows.h in project/src/backend/sdl/SDLWindow.cpp as far as I remember.

Thanks, I am now looking in to it. By the way, dynamically and statically linking Mingw Libs concerns GPL issues, so when we statically bind libstdc and libgcc, developers are forced instead to stick to GPL. If they dynamically link it, does that mean they could ship libstdc and libgcc dll files, together with their application, without GPL issue?

There were quite a lot of discussions about this topic, and all of them ends in redirection to lawyers with GPL and LGPL licenses. There is exclusion with dynamically linked gcc and stdc++ that removes AFAIK at least parts of restrictions.
It’s important to note that questions like “Can I sell my software compiled with MinGW and keep it proprietary (non-opensource)?” are unanswered directly.
With license change in LGPL 3.1 keeping licensing duties is quite hard (keeping source for all LGPL libs online for at least 3 years with instructions how to build those libs). On the other hand I don’t know whether gcc and stdc++ rely on LGPL, or have some exclusion from GPL, which isn’t LGPL actually. I don’t have yet nothing to sell :slight_smile: but I think I will mail GNU someday about it (maybe they will not send me to a lawyer :slight_smile: )
Actually, here is the text itself:
http://www.gnu.org/licenses/gcc-exception-3.1-faq.html
https://gcc.gnu.org/onlinedocs/libstdc++/manual/license.html

Ah, there is winpthreads.dll linkage also in new mingws, so there is one more lib to license check:)