Error cross compiling from linux to windows

[Ramshell]

Has anyone had this error? g++: error: unrecognized command-line option ‘-W3’; did you mean ‘-W’? It seems that SConstruct is not recognizing the mingw compiler :thinking:

For more context. I'm in ubuntu 21.04, and this error occurs when I try to compile to windows with scons platform=windows target=release -j 4

[TheSHEEEP]

Sorry, I don't officially support mingw. You can check out the SConstruct file yourself (it's just Python code, really). It does set the W3 flag and no, there is no check for mingw.

However, feel free to post a patch or pull request that'll make it work with mingw!

[Ramshell]

Oh, no problem. Actually, I was using mingw just because. I just want to be able to compile it to windows regardless of the compiler. Is it supposed to work out of the box with the godot-cpp setup?

[TheSHEEEP]

You mean, compiling godot-cpp with mingw? I think so, at least MinGW-w64 is mentioned in the Godot docs.

Or godotdetour on Windows with Visual Studio? I haven't tried it myself, but since I haven't received any reports of it not working, I'd assume that it does.

[Ramshell]

I mean compiling godotdetour on Linux to Windows. If I understand correctly, that's needed to then export a game to windows and linux. I mean having the addon compiled for both targets.

[TheSHEEEP]

Sure, that would be needed. But as I said, it's not something that I officially support or ever tried. So, it could end up working - or not.

Nothing in the code was written platform specific, so I'd say it probably should work - at least if recast/detour itself works with mingw. I don't see any mention of mingw in the recast/detour repo or its issues, so it's pretty much a matter of try and find out ;)

[Ramshell]

Have you tried exporting a game using the addon to windows from linux? I'm actually not sure if it's needed to compile it to windows for that.

[TheSHEEEP]

I haven't tried that, no. But given that GDNative modules are added to a project in Godot by pointing them directly to their compiled dynamic library files (see, https://github.com/TheSHEEEP/godotdetour/blob/master/demo/addons/godotdetour/godotdetour.gdnlib ), I don't see how you could get away without having a godotdetour.dll file. Godot projects can't just use the raw C++ code (that would be amazing, though! xD ).

[Ramshell]

In the end, I couldn't make scons to output a proper .dll in linux. So I gave up and compile it using windows. So sad though.

Thanks so much for answering everything!!

[founderio]

To cross-compile from Linux to Windows you need to set up MinGW-specific options. This should get you in the right direction (not tested, I have a different build structure than in this project, but it should get you closer to the goal)

# At the top:
import platform

# Replace the windows part with something like this:
elif env['platform'] == "windows":
    env['target_path'] += 'win64/'
    cpp_library += '.windows'
    if platform.system() == 'linux' or platform.system() == 'osx':
        env.Tool('mingw')

        # mingw with g++
        env['CC'] = 'x86_64-w64-mingw32-gcc'
        env['CXX'] = 'x86_64-w64-mingw32-g++'
        env['RANLIB'] = "x86_64-w64-mingw32-ranlib"
        env['LINK'] = "x86_64-w64-mingw32-g++"

        if env['target'] in ('debug', 'd'):
            env.Append(CCFLAGS=['-g3', '-Og'])
            env.Append(CXXFLAGS=['-std=c++17'])
        else:
            env.Append(CCFLAGS=['-g', '-O3'])
            env.Append(CXXFLAGS=['-std=c++17'])

        # Prevent name *.so, use *.dll
        env["SHLIBSUFFIX"] = ".dll"
        env["SHLIBPREFIX"] = "lib" # This needs to match what is referened in *.gdnlib - blank this, if there is no lib prefix there
        # Next to the DLL, a shared lib for linking is also created - both are required if you want to link to this lib (not required for godot addon)
        env["LIBSUFFIX"] = ".a"
        env["LIBPREFIX"] = "lib"
        # Intermediate object files named like on windows - optional
        env["OBJSUFFIX"] = ".obj"

        # Static linking of gcc libs to prevent them being required as dll
        #env.Append(LDFLAGS=["-static-libgcc", "-static-libstdc++"])
        # FIXME: static linking does not seem to work, regardless of which flags collection we do this in.
        # Workaround for now: Copy them to the bin directory and include them in export (gdnlib definition handles that).
        env["COPY_LIBS"] = ['libgcc_s_seh-1', 'libstdc++-6', 'libwinpthread-1']
        for lib in env["COPY_LIBS"]:
            libfile = lib + ".dll"
            target = '#' + env['target_path'] + libfile
            source = os.path.join(env['mingw_sys_root'], 'bin', libfile)
            Default(env.Command(target, source, Copy("$TARGET", "$SOURCE")))
    else: # Compiling on Windows (probably)
        # This makes sure to keep the session environment variables on windows,
        # that way you can run scons in a vs 2017 prompt and it will find all the required tools
        env.Append(ENV=os.environ)

        env.Append(CPPDEFINES=['WIN32', '_WIN32', '_WINDOWS', '_CRT_SECURE_NO_WARNINGS'])
        env.Append(CCFLAGS=['-W3', '-GR'])
        if env['target'] in ('debug', 'd'):
            env.Append(CPPDEFINES=['_DEBUG'])
            env.Append(CCFLAGS=['-EHsc', '-MDd', '-ZI'])
            env.Append(LINKFLAGS=['-DEBUG'])
        else:
            env.Append(CPPDEFINES=['NDEBUG'])
            env.Append(CCFLAGS=['-O2', '-EHsc', '-MD'])

I recommend testing without the env["COPY_LIBS"] part first, might be specific to some std:: functions we use in our project.

This is a simplified extract from a project with is cross-compiled from linux to windows, using stock mingw on Fedora 33.