Compiling windows cpp from linux using minGW, Its Possible!

Haxe
#1

How do we compiled openfl windows cpp from Linux using MinGW?

#2

You can’t do that, that’s not how compilers work. Compilers are designed to build source for the platform you’re currently using, not for a platform you’re not using. It’s the same reason you can’t just build a Mac application using openfl build mac on Windows.

It will look like it works because hxcpp has the source for it, but to properly deploy it will still require the native Mac bindings, which you can’t do without a Mac.

Cross-compiler environments could be done, however, using MXE which works with MingW compilers. Download OpenFL and build using openfl build linux on a dummy project to get the C++ generated source code. You might need to create a class that imports literally everything the openfl project has if you want to build the entire library.

Create a makefile in the generated directory that has the following contents:

SRC=[entry point].cpp
OBJ=$(SRC:.c=.o)
EXE=[project].exe
CC=$(CROSS)gcc
CFLAGS=-Wall -O3
LD=$(CROSS)ld
AR=$(CROSS)ar
PKG_CONFIG=$(CROSS)pkg-config
%.o: %.c
    $(CC) $(CFLAGS) -o $@ -c $<

Then cd to the directory in command line and do:

make CROSS=i686-w64-mingw32.static-

This will generate an exe file compiled using MingW and MXE. This is untested, so I am unsure if that will actually work, and good luck using it for anything other than experimentation, because building OpenFL seems a little far fetched since I don’t see any reason why you would want to.

The alternative is to produce an *.ndll file using hxcpp, which would make more sense, but again seems nonsensical since the haxe source already exists and using openfl build [target] will build and generate the source code for the given target anyway. Again, given that you have the tools to do so. Building for iOS requires a Mac and Xcode, for example.

This is until a point where OpenFL can provide build servers for us, but that would be a very expensive endeavour and if such a thing were to happen, expect to pay for the privilege :wink:

References:

  1. http://oldwiki.mingw.org/index.php/Makefile
  2. http://mxe.cc/#tutorial

UPDATE:

This is, as explained above, because hxcpp requires the native bindings required to produce the exe/app/linux file that can then be “executable” because without these native bindings it would be almost impossible.

Again, it may be possibly by using a cross-compiler such as one as I explained above, or by using a command which would use a different compiler:

openfl build windows -linker mingw

Although I’m not actually 100% sure on the command to tell hxcpp to use a different toolchain, so maybe someone can correct me on that.

2 Likes
#3

Native bindings is now making sense to me, I got a full working windows OS together with my Linux, I will try to copy some files needed on compile directory, if and only if mingw is bugless, I believe we can make this work once we know the native files hxcpp uses, unless of course if hxcpp has a native calls to the Windows registry, then that would be harder.

#4

UPDATE:

As far as I have tested on our Windows OS (Win 10), “openfl build windows” build successfully using mingw64! :slight_smile:

Well I have got to manually copy the files libgcc_s_dw2-1.dll and libstdc+±6.dll from mingw64 to Export/Windows/cpp/bin.

Now, I am trying to cross compile from Linux using mingw64 but I get error:

You must have a "project.xml" file or specify another valid project file when using the 'build' command

But I got that file there, build flash went ok. What am I missing?

#5

It’s likely the openfl command isn’t setup properly on your Linux system. You can either set the PATH environment to your OpenFL folder, or you can type it out the long way:

haxelib run openfl build project.xml windows
#6

This is great! Cross Compiling form Linux to Windows is possible! I just made it! :smile:

I will highlight to you guys how I did it.

In my Linux Machine (Fedora 21 x86_64) I

  1. Installed

    mingw32 mingw32-gcc-c++ mingw32-headers mingw32-crt mingw-winpthreads mingw32-cpp mingw32-filesystem

  2. Generate the linux source using

    haxelib run openfl build linux -32

  3. Navigate to Export/linux

  4. copy cpp to cpp_win

  5. navigate to cpp_win then delete the contents of bin folder exept for the assets

  6. open the terminal the type: ./launch (launch file)

  7. then type: make (Makefile)

  8. then type: strip ApplicationMain.exe

  9. copy the EXE file to the bin directory

  10. copy the Windows counterpart of the following files to bin directory (these files can be found from your haxe directory)
    a.) lime.ndll
    b.) regexp.dll
    c.) std.dll
    d.) zlib.dll

  11. copy the following files from your mingw32 directory to bin directory
    a.) libgcc_s_dw2-1.dll (i got these from windows version of mingw)
    b.) libstdc+±6.dll
    c.) libgcc_s_sjlj-1.dll
    d.) libwinpthread-1.dll

  12. done! you got your application cross compile

The attached download links from number 6 and 7 could be obtained by copying the output of CMD from Windows when compiling in Windows it self. I just changed the compiler location and include directory to match with my Linux Machine. Well I believe this is already implemented and there is already an existing mingw-toolchain but only for Windows. But i dont know xml unfortunately, and i dont know how to tell openfl/lime how to use the above procedure.

TEST Platform:

  1. Wine
  2. Windows 7

OTHERS:

  1. Everything works so far, Events, Assets (PNG), Actuate, OpenFl #includes.

Somebody good could write an xml toolchain based on the above procedure then push it to lime/openfl and hxcpp?

3 Likes
#7

Yeah, it sounds like we should do something in the WindowsPlatform.hx class of the tools, something like:

if (PlatformHelper.hostPlatform != Platform.WINDOWS) {
    
    flags.push ("-Dmingw");
    
}

There should probably be guards around similar things like the “ReplaceVistaIcon.exe” call, which wouldn’t work on another platform

#8

@singmajesty there’s already a check like this to trigger cross-platform neko build
but maybe this could be overridden from the command line lime build windows -Dmingw to not use neko but mingw instead.

#9

Or I was thinking, mingw could be default for desktop cross-windows builds, but “-neko” would force cross-desktop Neko builds?

#10

I tried to edit the WindowsPlatform.hx but no luck in making it force in cpp from my Linux machine.

if (project.targetFlags.exists ("neko")) {
        
    targetType = "neko";
        
} else if (project.targetFlags.exists ("nodejs")) {
    
    targetType = "nodejs";
        
} else if (project.target == PlatformHelper.hostPlatform || PlatformHelper.hostPlatform == Platform.LINUX) {

     targetType = "cpp";

} else {
        
    targetType = "neko";
        
}
#11

After editing that file (or any other file in that folder), you need to run “lime rebuild tools” for your changes to take effect.

#12

It looks like there’s a check here:

https://github.com/openfl/lime/blob/master/lime/project/ProjectXMLParser.hx#L82

Then I would do something like else { targetType = "cpp"; but do a check for if (PlatformHelper.hostPlatform != Platform.WINDOWS) to add a define for mingw

#13

Now checking projectxmlparser.hx too! :smile:

But I get stuck somewhere after I edited the windowsplatform.hx to build cpp,

else if (project.target == PlatformHelper.hostPlatform || PlatformHelper.hostPlatform == Platform.LINUX) {

    targetType = "cpp";

}

then did this

haxelib run lime rebuild tools

When I tried to

haxelib run openfl build windows

I was expecting that it will try to detect Windows cpp like g++.exe or VC++, but when it finds Platform.Linux it creates a cpp folder within windows then built a Linux binary there. I think somewhere else there is a trigger that automatically builds native cpp for a specific platform, I just could not find it.

#14

Maybe the compile flags need “-Dwindows” added

#15

So after adding “-Dwindows” this will now call on hxcpp to do the compiling?

I have also opened a new issue to hxcpp in git so they can update it as well.

#16

I think it runs something like “haxelib run hxcpp Build.xml” but I think for cross-builds we want “haxelib run hxcpp Build.xml -Dwindows -Dmingw” so we’ll need to pass the correct flags to the CPPHelper for the compile :slight_smile:

#17

When I checked the final.hx file it contains -D windows and -D mingw, but it still compiles to native Linux cpp.

It always calls on linux-toolchain.xml, regardless of changes I made previously.

I will try that, and if it works, I think it could be added to the commands array.

#18

Check the WindowsPlatform.hx code, there are “flags” for the C++ compile step as well as “args” to the Haxe compile step, you need to pass them to the C++ compile step, I think

#19

Ok, I will try it, I am just bothered that even when -D windows and -D mingw is on the compile flags of “final.hx” it still compiles Linux.

#20

If that doesn’t work, you might need to do “-Dtoolchain=mingw” or something like that