Skip to content

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

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
enetheru opened this issue Dec 13, 2024 · 4 comments
Labels
platform:windows topic:buildsystem Related to the buildsystem or CI setup
Milestone

Comments

@enetheru
Copy link
Collaborator

enetheru commented Dec 13, 2024

godot-cpp version

27ffd8c

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 dsnopek added platform:windows topic:buildsystem Related to the buildsystem or CI setup labels Jan 21, 2025
@dsnopek dsnopek added this to the 4.x milestone Jan 21, 2025
enetheru added a commit to enetheru/godot-cpp that referenced this issue Jan 23, 2025
As described in issue godotengine#1672 msys2 environments don't use a mingw prefix for their compiler binaries.

this patch detects MSYSTEM environment variable detects compilers directly
enetheru added a commit to enetheru/godot-cpp that referenced this issue Jan 23, 2025
As described in issue godotengine#1672 msys2 environments don't use a mingw prefix for their compiler binaries.

this patch detects MSYSTEM environment variable detects compilers directly
enetheru added a commit to enetheru/godot-cpp that referenced this issue Jan 30, 2025
As described in issue godotengine#1672 msys2 environments don't use a mingw prefix for their compiler binaries.

this patch detects MSYSTEM environment variable detects compilers directly
enetheru added a commit to enetheru/godot-cpp that referenced this issue Feb 2, 2025
As described in issue godotengine#1672 msys2 environments don't use a mingw prefix for their compiler binaries.

this patch detects MSYSTEM environment variable detects compilers directly
enetheru added a commit to enetheru/godot-cpp that referenced this issue Feb 3, 2025
As described in issue godotengine#1672 msys2 environments don't use a mingw prefix for their compiler binaries.

this patch detects MSYSTEM environment variable detects compilers directly
enetheru added a commit to enetheru/godot-cpp that referenced this issue Feb 4, 2025
As described in issue godotengine#1672 msys2 environments don't use a mingw prefix for their compiler binaries.

this patch detects MSYSTEM environment variable detects compilers directly
enetheru added a commit to enetheru/godot-cpp that referenced this issue Feb 8, 2025
As described in issue godotengine#1672 msys2 environments don't use a mingw prefix for their compiler binaries.

this patch detects MSYSTEM environment variable detects compilers directly
enetheru added a commit to enetheru/godot-cpp that referenced this issue Mar 7, 2025
As described in issue godotengine#1672 msys2 environments don't use a mingw prefix for their compiler binaries.

this patch detects MSYSTEM environment variable detects compilers directly
@dsnopek
Copy link
Collaborator

dsnopek commented Mar 13, 2025

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
Copy link
Collaborator Author

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
Copy link
Collaborator

dsnopek commented Mar 14, 2025

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
Copy link
Collaborator Author

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
platform:windows topic:buildsystem Related to the buildsystem or CI setup
Projects
None yet
Development

No branches or pull requests

2 participants