Godot: Compilation problem: stuck on linking static library with MinGW on Windows

[Altair1234]

Cloned the latest version. The same problem last time around as well.

Stuck on moduleslibmodules.windows.tools.64.a

Earlier I thought that it's a big file so might be taking time but I see similar issues (#5182 & 5276) and that makes me think it might be a bug. Using cmder in Windows as terminal with Mingw. Installed everything using scoop.

[novhack]

I have a same issue with the latest master so I can confirm.

[yaelatletl]

This has happened to me, I installed everything with scoop aswell.
it stops at progress_finish(["progress_finish"], [])
Specs: Ryzen 7 3700x, RX5700, 32GB DDR4.
Multi-thread compilation.

[ripperdave]

The same here.

[Initial build] Linking Static Library ==> modules\libmodules.windows.tools.64.a
=====
b"C:/Users/xxxx/scoop/apps/gcc/current/bin/../lib/gcc/x86_64-w64-mingw32/8.1.0/../../../../x86_64-w64-mingw32/bin/ar.exe: unable to rename 'modules\\libmodules.windows.tools.64.a'; reason: File exists\r\n"
=====
scons: *** [modules\libmodules.windows.tools.64.a] Error 1
scons: building terminated because of errors.

[waterdu]

any update

[AlexGHz1]

I thought I was the only one who had that happen.
I have tried to compile the master version using multithreading, but it always gets stuck in the final part:

[Initial build] progress_finish(["progress_finish"], [])
[Initial build] ←[91mLinking Static Library ←[95m==> ←[93mmodules\freetype\libfr
eetype_builtin.windows.tools.64.a←[0m
[Initial build] ←[91mRanlib Library         ←[95m==> ←[93mmodules\freetype\libfr
eetype_builtin.windows.tools.64.a←[0m
[Initial build] ←[91mLinking Static Library ←[95m==> ←[93mcore\libcore.windows.t
ools.64.a←[0m
←[91mRanlib Library         ←[95m==> ←[93mcore\libcore.windows.tools.64.a←[0m
[Initial build] =====

[bvdelft]

I have tried switching branches and reverting to and older version (march 2019), using single thread compilation, but kept getting the same issue. I did succeed when switching from MinGW to Visual Studio. So I'd say it is more likely to be an issue with the latest version of MinGW (or one of the build tools used in it).
I'd suspect using an older version of MinGW might help, but have not had the chance to try that.

[akien-mga]

Some ideas:

• Try to build with -j1 to rule out parallel build issues (which were a problem in #12516)
• Try to install make if it's the same problem as #12516, though I'm not sure why it's needed
• Check if installing Pywin32 fixes it. It used to be listed as a requirement for parallel builds, I'm not sure why it was removed: http://docs.godotengine.org/en/3.0/development/compiling/compiling_for_windows.html#requirements

[Calinou]

Check if installing Pywin32 fixes it. It used to be listed as a requirement for parallel builds, I'm not sure why it was removed: http://docs.godotengine.org/en/3.0/development/compiling/compiling_for_windows.html#requirements

I removed the Pywin32 requirement in the documentation, since I noticed Godot was able to build successfully when using multiple threads without Pywin32. This may be due to our buildsystem using subprocesses to bypass Windows-specific issues.

However, we can't remove the warning message when building as it's printed by SCons itself.

[Chaosus]

@akien-mga Unfortunately it doesn't work... The build is stuck in either case.

[AlexGHz1]

I have tried switching branches and reverting to and older version (march 2019), using single thread compilation, but kept getting the same issue. I did succeed when switching from MinGW to Visual Studio. So I'd say it is more likely to be an issue with the latest version of MinGW (or one of the build tools used in it).
I'd suspect using an older version of MinGW might help, but have not had the chance to try that.

I´m going to try it.

[AlexGHz1]

@akien-mga Unfortunately it doesn't work... The build is stuck in either case.

With MinGW and Visual Studio?

[Chaosus]

I mean with or without Akien's advice ^^ This issue is about MinGW

[tinmanjuggernaut]

I just performed a clean build of master without issue (aside from linking taking forever (3-5 min?) but that's normal). None of my builds on windows or linux have ever not completed or not errored out.

These components were not installed via scoop. I did install make via scoop for the multithreaded use_lto issue per #12156, but the executable doesn't work with LTO.

Win10/64
gcc version 8.1.0 (x86_64-posix-seh-rev0, Built by MinGW-W64 project)
Python 3.7.3
pywin32
scons: v3.0.5.a56bb

scons.py platform=windows use_mingw=yes target=release_debug -j12

[clayjohn]

In my case it didn't appear completely stuck. I left it at the linking stage for 3 hours. During which time libmodules slowly grew to be over 300 mb.

[Altair1234]

I might not be giving it enough time with my sixth gen i5 mobile processor.

[panshouren]

In my case it didn't appear completely stuck. I left it at the linking stage for 3 hours. During which time libmodules slowly grew to be over 300 mb.

I waited for a long time and finally it succeeded. The libmodules.windows.tools.64.a only grows a few kb per second. XD.

[akien-mga]

I installed MinGW on Windows 10 via MSYS2, and I can reproduce the issue. As noticed by @clayjohn, linking does work but it simply takes a decade. I'm not sure what changed in Godot or in the toolchains as it used to build fine in the past. Might be worth trying other linkers if available for Windows.

I did install make via scoop for the multithreaded use_lto issue per #12156, but the executable doesn't work with LTO.

Check that you have mingw-binutils >= 2.33, otherwise you would be affected by #24641.