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 . 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?
Maybe it could be pushed into macosx also with crosscompilation
Cool, It could be pushed, but I dont have Mac to do some test.
I got the shader problem on 2.7.x, now even neko cross-compile dont work.
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ā¦ 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
I forked Lime and added MinGW support here:
Great to hear that!
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 but I think I will mail GNU someday about it (maybe they will not send me to a lawyer )
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
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.
And there is macosx crosscompilation in the list, maybe Itāll be doable also