Using Scons with Msys2

[abhaskumarsinha]

Hello, I've a problem while using msys2

I want to compile an Open-Source Game Engine Called Godot Game Engine - Godot Game Engine.

It's a Free and Open Source Game Engine Based on OpenGL API.

The Instructions to compile Godot Under Linux - Godot Docs

As we can See, It needs few Libraries and tools -

GCC or Clang Python 2.7+ (Python 3 only supported as of SCons 3.0) SCons build system pkg-config (used to detect the dependencies below) X11, Xcursor, Xinerama, Xi and XRandR development libraries MesaGL development libraries ALSA development libraries PulseAudio development libraries (for sound support) Freetype (for the editor) OpenSSL (for HTTPS and TLS) Optional - libudev (build with udev=yes) Optional - yasm (for WebM SIMD optimizations)

Since, msys2 is using Pacman like Arch Linux, So, the oneliner for Arch Linux is this -

pacman -S scons libxcursor libxinerama libxi libxrandr mesa glu alsa-lib pulseaudio freetype2
--

But, I dunno why it doesn't work and shows the error like here -

VAIO@VAIO-PC MINGW32 ~
$ pacman -S scons libxcursor libxinerama libxi libxrandr mesa glu alsa-lib pulseaudio freetype2
warning: scons-2.5.1-1 is up to date -- reinstalling
error: target not found: libxcursor
error: target not found: libxinerama
error: target not found: libxi
error: target not found: libxrandr
error: target not found: mesa
error: target not found: glu
error: target not found: alsa-lib
error: target not found: pulseaudio
error: target not found: freetype2

VAIO@VAIO-PC MINGW32 ~
$

Also, I tried manually Installing Some of them, which I succeeded to some extent, but Libraries like X11, Xcursor, Xi, etc. aren't there even when I try searching them using pacman -Ss xcursor

When I try to use Scons to Compile from source using this command - scons platform=windows, it shows this error message -

$ scons platform=windows
scons: Reading SConscript files ...
Package x11 was not found in the pkg-config search path.
Perhaps you should add the directory containing `x11.pc'
to the PKG_CONFIG_PATH environment variable
No package 'x11' found
X11 not found.. x11 disabled.
Configuring for Windows: target=debug, bits=default
Using Mingw
YASM is necessary for WebM SIMD optimizations.
WebM SIMD optimizations are disabled. Check if your CPU architecture, CPU bits or platform are supported!
Checking for C header file mntent.h... (cached) no
scons: done reading SConscript files.
scons: Building targets ...
[Initial build] Compiling ==> platform/windows/godot_win.cpp
sh: x86_64-w64-mingw32-g++: command not found
scons: *** [platform/windows/godot_win.windows.tools.64.o] Error 127
scons: building terminated because of errors.

It shows that x86_64-w64-mingw32-g++ is missing.

So, I don't know if it's a bug or what I'm just a Web Developer, everything seems daunting, I think if I get some guide, then It can help me in Compiling Godot.

Msys2 Docs didn't help much :(

For some Reason - I can't use Visual Code by Microsoft.

Thanks in Advance

[StarWolf3000]

It looks for x86_64-w64-mingw32 prefix (assuming its looking for the 32-bit compiler environment), but the actual prefix is mingw-w64-x86_64 (for 64-bit compiler environment) and mingw-w64-i686 (32-bit environment).

The prefix x86_64-w64-mingw32 is the original 32-bit prefix from the MINGW-w64 project.

Even since MSYS2 uses pacman as package manager doesn't mean all Arch Linux packages are available on the Windows platform. So it's no wonder that pacman -S libxcursor libxinerama libxi libxrandr mesa glu alsa-lib pulseaudio freetype2 isn't working, since those packages aren't part of MSYS2. In addition to that, the development tools of MSYS2 itself only contain everything neccesary to build or port applications FOR MSYS2 itself (like the Unix Coreutils or GCC or everything non-development related).

To build a non-MSYS2 library or application from source, you need to install the MSYS2-MINGW versions of the packages and run the MINGW shell instead of the MSYS2 shell (there's a difference in some env variables). However there's a catch here with what you are trying to do: The X packages, alsa, pulseaudio and glu don't exist for the MSYS2/MINGW-w64 platform, so trying this pacman -S mingw-w64-i686-libxcursor mingw-w64-i686-libxinerama mingw-w64-i686-libxi mingw-w64-i686-libxrandr mingw-w64-i686-mesa mingw-w64-i686-glu mingw-w64-i686-alsa-lib mingw-w64-i686-pulseaudio mingw-w64-i686-freetype will output the following errors:

error: target not found: mingw-w64-i686-libxcursor
error: target not found: mingw-w64-i686-libxinerama
error: target not found: mingw-w64-i686-libxi
error: target not found: mingw-w64-i686-libxrandr
error: target not found: mingw-w64-i686-glu
error: target not found: mingw-w64-i686-alsa-lib
error: target not found: mingw-w64-i686-pulseaudio

Target should also be Unix, not Mingw for SCons. MingW assumes, that you're using MINGW-w64 or the old classic MINGW (which was last updated somewhere back in 2008/2009).

[bdbaddog]

SCons 3.0.0 and 3.0.1 support both Python 2.7 and 3.5+ (3.0.0 doesn't drop python 2.7 support)

[Anutrix]

Just a helpful note for anyone looking for it: I was able to compile Godot Engine on Windows(not Linux unlike OP). I did the following MSYS-related stuff:

1. Install and update(IMPORTANT) MSYS2(follow step by step on their homepage(https://www.msys2.org/)).
2. Install gcc-toolchain by running pacman -S mingw-w64-x86_64-toolchain (for 64 bit) or pacman -S mingw-w64-i686-toolchain(for 32 bit).
3. Add C:\msys64\mingw64\bin to Windows Environment Variable PATH.
4. Close/Restart all Command Prompts.

Next. Follow Godot Engine's compiling docs.

[StarWolf3000]

@Anutrix Step 3 is not necessary and should never be done, just start the MINGW64 shell (mingw64.exe).

[Anutrix]

@StarWolf3000 Godot uses scons to for its building which requires mingw-w64 to be in path. It wasn't detecting mingw-w64 till I did that. Also, Mingw-builds installer does that. It shouldn't be a problem unless you mess up. I haven't tried scons on MinGW-w64 shell yet(it will probably work fine but it's easier to open cmd in Project folder). Above should get it working in Command Prompt.

[StarWolf3000]

You can invoke scons from MINGW64 shell, as long as the scons package is installed.

[bdbaddog]

Hmm.SCons should find mingw if it's in one of a few "Default" paths. We've been tweaking those defaults lately. Which version of SCons are you using?

[Anutrix]

>scons -v
SCons by Steven Knight et al.:
        script: v3.0.5.a56bbd8c09fb219ab8a9673330ffcd55279219d0, 2019-03-26 23:16:31, by bdeegan on kufra
        engine: v3.0.5.a56bbd8c09fb219ab8a9673330ffcd55279219d0, 2019-03-26 23:16:31, by bdeegan on kufra
        engine path: ['C:\\Program Files\\Python37\\scons\\SCons']
Copyright (c) 2001 - 2019 The SCons Foundation

Note: I tried it in cmd.exe(Windows Command Prompt) not in msys2/mingw shell.

Update: I also tried the command in mingw64 shell and msys2 shells. It didn't work.

user@device MINGW64 /d/Godot/compile_space/godot
$ scons -j2 platform=windows
bash: scons: command not found

user@device MSYS /d/Godot/compile_space/godot
$ scons -j2 platform=windows
bash: scons: command not found

Maybe I need to install scons inside msys2 environment or something. Neither worth the effort nor worth the space.

[bdbaddog]

@Anutrix - You shouldn't need to install inside msys2 for this to work, But that is a fairly old version.

Please pull latest 3.1.2 which does address some issues finding mingw..

Ahh. yes it's not going to find scons as when installed on windows the script's named scons.bat. (assuming you installed it in a windows python0

[Anutrix]

@bdbaddog Thx. 3.0.5 seems to be the latest semi-major version before 3.1.2 so I didn't know it was old. Also because of https://github.com/SCons/scons/issues/1567 I don't see a way to uninstall it. Reinstalling Python(because I needed a cleanup anyway) but a better solution would be nice. Will update with the results soon.

[Anutrix]

C:\Users\theuser>python -m pip install --user scons
Requirement already satisfied: scons in c:\users\anutrix\appdata\roaming\python\python38\site-packages (3.1.2)

C:\Users\theuser>scons -v
'scons' is not recognized as an internal or external command,
operable program or batch file.

Any solutions? Or do we need to install it as global package without --user?

Update: Installing it globally worked. That is, scons 3.1.2 installed.

[Anutrix]

@bdbaddog SCons 3.1.2 in cmd.exe also can't detect MinGW if I remove C:\msys64\mingw64\bin from Windows Environment Variable PATH.

As for inside MSYS2 and MINGW shells:

user@device MINGW64 /d/Godot/compile_space/godot
$ scons -j2 platform=windows
bash: scons: command not found

user@device MSYS /d/Godot/compile_space/godot
$ scons -j2 platform=windows
bash: scons: command not found

It's the same.

[bdbaddog]

@Anutrix Just so I understand. You used the SCons windows installer (the .exe) to install scons and it installed against your python 3.7 install. Then it looks like you tried pip install which ran against your python 3.8 install? I'm adding some notes to https://github.com/SCons/scons/issues/1567 with specific instructions how to clean up after your scons installer.

[bdbaddog]

@Anutrix - can you try a new devel release with updated default list of mingw paths

pip install -i https://test.pypi.org/simple/ scons==3.1.3.dev20200308202948

[Anutrix]

I had 3.0.5 which installed with Python 3.7. I think I got it using setup.py which I downloaded a while ago.

Then after reading this post, I uninstalled Python 3.7 completely and installed Python 3.8.

Then installed latest scons from pip.

[Anutrix]

@Anutrix - can you try a new devel release with updated default list of mingw paths

pip install -i https://test.pypi.org/simple/ scons==3.1.3.dev20200308202948

This did not work either. Still need to install scons inside MSYS2 MinGW shell to make it work inside the shell or add mingw manually to Windows PATH to make it work outside.

[bdbaddog]

@Anutrix - can you try a new devel release with updated default list of mingw paths pip install -i https://test.pypi.org/simple/ scons==3.1.3.dev20200308202948

This did not work either. Still need to install scons inside MSYS2 MinGW shell to make it work inside the shell or add mingw manually to Windows PATH to make it work outside.

Did not work = didn't find mingw? or the compile didn't work?

[StarWolf3000]

@lazka Please intervene and review the issue and replies so far. I think this is going more and more into the wrong direction.

[YRTV]

Scons was never packaged for mingw subsystems. msys/scons runs on msys/python when invoked from any shell. Python returns OS:posix breaking the build. See https://github.com/godotengine/godot/issues/26032

[lazka]

hm, yeah from what I understand this is mostly about using external Python and scons builds using msys2 mingw gcc? Not really a msys2 problem then...

I would suggest that in case scons supports Windows Python and also supports mingw we should just package scons for the msys2 mingw subsystem (so that pacman -S mingw-w64-x86_64-scons works). But I don't know anything about scons.

I know @pal1000 has some experience compiling with scons under Windows, maybe he/she knows more.

[pal1000]

As far as I know Scons has some MinGW-w64 support as the only error experienced when compiling Mesa with it is this one. Hopefully Godot Engine won't trip it.

[YRTV]

https://github.com/SCons/scons/wiki/LongCmdLinesOnWin32

After some investigation, it turns out this is not a limitation of Windows, but a limitation of the C Runtime that MSVC uses (which Python was compiled with).

Is MSYS2 packages mingw-w64-i686-python and mingw-w64-x86_64-python compiled with MSVC runtime?

[StarWolf3000]

Is MSYS2 packages mingw-w64-i686-python and mingw-w64-x86_64-python compiled with MSVC runtime?

From what I know and ntldd says, the MINGW Python packages are native builds, so the answer is: yes

MINGW64 ~
$ ntldd python
        libpython3.8.dll => C:\msys64\mingw64\bin\libpython3.8.dll (0x0000000000fe0000)
        KERNEL32.dll => C:\WINDOWS\SYSTEM32\KERNEL32.dll (0x0000000000ee0000)
        msvcrt.dll => C:\WINDOWS\SYSTEM32\msvcrt.dll (0x0000000000ee0000)

MINGW64 ~
$ ntldd libpython3.8.dll
        ADVAPI32.dll => C:\WINDOWS\SYSTEM32\ADVAPI32.dll (0x0000000000cf0000)
        KERNEL32.dll => C:\WINDOWS\SYSTEM32\KERNEL32.dll (0x0000000001240000)
        msvcrt.dll => C:\WINDOWS\SYSTEM32\msvcrt.dll (0x0000000001240000)
        libwinpthread-1.dll => C:\msys64\mingw64\bin\libwinpthread-1.dll (0x0000000000020000)
        USER32.dll => C:\WINDOWS\SYSTEM32\USER32.dll (0x00000000012a0000)
        VERSION.dll => C:\WINDOWS\SYSTEM32\VERSION.dll (0x0000000000020000)
        WS2_32.dll => C:\WINDOWS\SYSTEM32\WS2_32.dll (0x0000000001400000)

[YRTV]

When if scons will be packaged for mingw subsystems it can be hit with bug @pal1000 mentioned. It seems scons upstrem must handle it, as it affects any windows python version.