Skip to content
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

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

Open
enetheru opened this issue Dec 13, 2024 · 0 comments

Comments

@enetheru
Copy link
Contributor

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant