SCons : When building using MSys2/clang64 SCons thinks it is cross-compiling due to picking up env: $MINGW_PREFIX

[enetheru]

trafficstars

godot-cpp version

27ffd8c6be614b283b1228c3f8476db25070c00f

System information

Windows 11, Msys2/clang64

Issue description

Compiling for Windows on Windows using the MSys2/clang64 environment shell. Using compile command: scons verbose=yes use_mingw=yes use_llvm=yes

SCons fails to archive the obj files using C:/msys64/clang64/bin/x86_64-w64-mingw32-ar.exe and supplies the following message:

C:/msys64/clang64/bin/x86_64-w64-mingw32-llvm-ar q <very long list of files>
...
scons: *** [bin/libgodot-cpp.windows.template_debug.x86_64.a] The system cannot find the file specified
scons: building terminated because of errors.

The missing file is C:/msys64/clang64/bin/x86_64-w64-mingw32-ar.exe

The reason this is, is because for all MSys2 environments $MINGW_PREFIX is set to the root path of their subshell. And SCons picks up that environment variable as the default to mingw_prefix. When it comes to selecting the compiler, it chooses the cross compiling path. Except there is a misnomer here, all of these environments are for compiling native windows, there is no cross compiling. SCons then adds a bunch of architecture triplet information and tries to use the resultant binary.

Its a miracle that it works for ucrt64, or others, and if those prefixed binaries weren't by happenstance to be in the $PATH then it would fail.

The prefixed binaries: C:\Msys2\$MINGW_PREFIX\bin\x86_64.w64.mingw32.<program>.exe are there for some, as yet unknown to me, convenience. Since the environments are native windows, and the prefix is for the host system, they aren't cross compilers at all, and can be ignored entirely, al of the actually useful binaries have no prefix as this isnt a cross compiler.

The way I've come to understand MSys environments is that you choose the subshell for the type of Windows build you want to make, and or the libraries you want to link to. Cross compiling is another kettle of fish layered ontop of this.

Msys Environments Table

Now, I'm not overly familiar with SCons, but I've been testing locally and here's what I have so far.

MSys environments conveniently define $MSYSTEM when one of the subshells are being used.

By using the $MINGW_PREFIX environment variable on the condition that $MSYSTEM is empty, I don't get the cross compile selection. And I can copy the use_llvm section from Linux to generate for clang.

# windows.py:6
from SCons.Tool import mingw, msvc, clangxx, clang

# ...

# windows.py:76
def options(opts):
    msystem = os.getenv("MSYSTEM", "")
    mingw_prefix=""
    if not msystem:
        mingw_prefix = os.getenv("MINGW_PREFIX", "")

    opts.Add("mingw_prefix", "MinGW prefix", mingw_prefix)

# ...

# windows.py:~133
    elif (sys.platform == "win32" or sys.platform == "msys") and not env["mingw_prefix"]:
        env["use_mingw"] = True
        if env["use_llvm"]:
            clang.generate(env)
            clangxx.generate(env)
        else:
            mingw.generate(env)

I get a successful build, I haven't checked if any of the options are correct or what is missing tho.

AFAICT this also doesn't interfere with choosing a mingw_prefix for doing some actual cross compiling, but I am not yet upto testing that.

Cheers, Samuel.

Steps to reproduce

try to compile godot-cpp using MSys2 / clang64 environment. Build Command: scons verbose=yes use_mingw=yes use_llvm=yes

Minimal reproduction project

the godot-cpp source code. or test

[dsnopek]

Why are you specifying both use_mingw=yes and use_llvm=yes? Aren't those supposed to be mutually exclusive (using either GCC or clang, but not both)?

[enetheru]

Why are you specifying both use_mingw=yes and use_llvm=yes? Aren't those supposed to be mutually exclusive (using either GCC or clang, but not both)?

They aren't mutually exclusive, llvm/clang can be built with and linked against the mingw toochain/runtime. There are a couple of compiler projects available that I know of and have tested.

• llvm-mingw
• Msys2 based clang compilers are linked against mingw.

So for instance, I can set a mingw_prefix to the root of my llvm-mingw folder, and set my arch and it will cross compile. it has x86_32, x86_64, arm32, arm64 and works quite well.

Compile command would look like: scons platform=windows arch=x86_64 use_mingw=yes use_llvm=yes mingw_prefix=C:/llvm-mingw target=template_release

---

There are some fundamentals which are weird, like testing sys.platform == "msys".

As of testing today, the MSYS environment python reports sys.platform == 'cygwin' all other MSYS environments, aka UCRT64, CLANG64, etc report sys.platform == 'win32' I'm unaware of when that might have reported 'msys' in the past.

Maybe helpful commit in Godot from @bruvzg from 2022

I dunno, I'm not so confident with SCons to propose a robust solition atm.

[dsnopek]

Hm, ok. This might need input from folks with more platform and build system expertise than me. I'm not sure if our build system (or Godot's) is designed to anticipate using both mingw (which usually means GCC) and LLVM (which usually means clang) together.

In general, I think we should follow Godot's lead, and if Godot is handling this in a particular way, then we should handle it that way too.

[enetheru]

In general, I think we should follow Godot's lead, and if Godot is handling this in a particular way, then we should handle it that way too.

I was looking at the godot source to see if i could replicate as they do handle the case, but it would take me considerable time to understand their solution. Given I am the only person who has reported it so far, I'm going to put it on the back burner, because it only becomes a problem for a single configuraiton of MSys2/clang where ar.exe isnt prefixed