CLion/Mingw64 slow linker on windows

Hi there, I’m working on a CLion project on mac/windows and while on mac my linker is pretty fast, I’m experiencing extremely long link times on Windows.

My toolchain on windows is based on : mingw-w64\x86_64-8.1.0-posix-seh-rt_v6-rev0

So far :
(1) tried to use the gold linker with “fuse-ld=gold” option on projucer extra linker options, but I’m getting some unknown input errors to so I probably need more flags I’m not aware of.
(2) tried switching to llvm, using this but I’m in the middle of nothing compiling anymore, not even juce code.

Has anyone experienced the same problem and got through it succesfully , either via (1) || (2) or with some other alternative?

I witnessed the extreme slowness of the MinGW linker, and the only solution I’ve found is to use MSVC (the toolchain that comes with Visual Studio).

I never tried using the gold linker though. I would be happy to help you figure out why it doesn’t work, if you want.

Using clang/LLVM isn’t possible currently, because the JUCE code assumes that #if defined(__clang__) means macOS or Linux.

1 Like


Really appreciate any help here since I’m a real noob in the toolchain world.

So… i’m adding -fuse-ld=gold to my projucer codeblocks extra linker flags (then funneled to cLion cmakelists via projucer… very keen on working with projucer with no manual extra steps unless completely unavoidable…)

and the error I’m getting is the following:

C:/PROGRA~1/MINGW-~1/X86_64~1.0-P/mingw64/bin/…/lib/gcc/x86_64-w64-mingw32/8.1.0/…/…/…/…/x86_64-w64-mingw32/bin/ --subsystem: unknown option
C:/PROGRA~1/MINGW-~1/X86_64~1.0-P/mingw64/bin/…/lib/gcc/x86_64-w64-mingw32/8.1.0/…/…/…/…/x86_64-w64-mingw32/bin/ use the --help option for usage information
collect2.exe: error: ld returned 1 exit status

So great news is gets invoked. Bad news is that probably it’s getting an option (–subsystem ?) that ld was merrily digesting, but does not.

if you have ideas on a possible next step I’ll be happy to execute :pray:

Ok some more stuff I found , which 99.9% shuts down the gold liker hope on Clion/Mingw64 running on windows 10:

  1. gold linker outputs only ELF type executables, as opposed to windows PE type .exes (see : …so some say it should eve NOT be included in Mingw windows distro (see :
  2. another option - further than setting up the MSVC toolchain, could be to cross compile to windows from a linux dev machine i.e. compile to ELF format then add a post build 3rd party ELF to PE tool , possibility mentioned here :

Might spend some (very little) effort trying some of (2) - since the MSVC toolchain is not an option for my particular use case.

May I ask why is that?

1 Like

Just meaning that the optimal goal is to improve things leaving the environment as is, since I have a rust + C++ app that is managed very well in Clion as one “single” item.
Not very keen on setting up a pre-build phase in msvc to build the rust library, not sure of the hurdles I’d get … but as I’m speaking this is actually becoming more and more something i’ll have to go for, since there’s no way out of this speed wise.

What do you mean by “in msvc”? What I refer to as “the MSVC toolchain” is the compiler (cl) and linker (link), like LLVM with clang and lld. So I’m a bit confused by what a “pre-build phase in msvc” would be.

You can use the MSVC toolchain in CLion. You don’t have to use Visual Studio.

Yes but then you can no longer use the Projucer (currently) to export and manage the project, as the Windows CodeBlocks exporter only supports MinGW. So the sacrifice is to break out of Projucer. Which I guess is fine in some cases.

yes, having a juce project (so .jucer file stays up to date and drives the build) on windows AFAIK means no msvc toolchain canc be involved)

so that’s why I’m thinking of moving to the MSVC windows exporter , despite loving to be able to fix this issue staying in clion