Beginner Question: MingwSupport

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:)

Hopefully not, so I guess, we got to update hxcpp allow this kind of flexibility. Currently hxcpp cross-compile allows only static linking of libstdc++ & libgcc due to compatibility problems with dynamic linking:

1.) Dynamic linking requires libgcc_s_dw2-1.dll which unfortunately only available to Windows version of Mingw, thus preventing Linux users to do cross-compile. Unless of course they are willing to download 1Gb of files just to get it.

2.) The location and file name of libgcc_s_sjlj-1.dll varies across OSes, making mingw cross-compilation difficult to integrate into hxcpp.

If somebody got better ideas, I think we could make some pr and look forward that Hugh merged it :slight_smile:

Iā€™ll take look at proper configuration, but firstly Iā€™ll try to work upon good crosscompilation support without manually file copying between folders etc. :wink:
And there is macosx crosscompilation in the list, maybe Itā€™ll be doable also :slight_smile: