Linker running out of heap memory

I started getting build fail due to linker running out of heap space.
I am on visual studio 2019 , win10 x64 32gb ram.
I was able to fix that issue by changing “Preferred Build Tool Architecture” from “default” to “64-bit (x64)” in the project configuration properties.
The issue now is that everytime i restart the project the setting gets overwritten by the projucer…
How can i make that setting stick?

Looks like there could be a compiler flag that makes Visual Studio output the full paths to the compiler tools it is using. This would confirm whether or not the 64-bit linker is being used.

Check out the “Choice of toolset is important” section of this page.

This could be added to the “Extra Compiler Flags” section of the jucer project.

Set the environment variable PreferredToolArchitecture to x64

2 Likes

@G-Mon is right. The compiler option just makes Visual Studio output the paths to the compiler tools so that you can check that the correct ones are being used.

Setting the environment variable seems to work.
thanks.

Hello, we have similar issues, where is this variable please? :wink:

Windows Key + Break

From there, select “Advanced system settings” → “Environment Variables”.

1 Like

Awesome, thanks :wink:

I’m running into this same issue. Can someone explain how to correct this in Projucer (not the VS project)?

I tried setting the environment variable with no success.

Have you tried using the Extra Compiler flag: /bigobj

Rail

**/bigobj** increases the number of sections that an object file can contain.

Not quite the same thing as specifying the preferred toolset…?

set PreferredToolArchitecture=x64 looks promising. Perhaps you can put that in the pre-build command section?

I tried a bunch of combinations and ended up with:

in Extra Compiler Flags, I added:
/bigobj

in Pre-Build Command, I added:
set PreferredToolArchitecture=x64

And also set BinaryData.cpp size limit to:
20mb

THEN it finally compiled & linked in VS2019. None of those were needed in VS2017.

After quite a bit of googling, it looks like Microsoft supposedly fixed several bugs about default toolset, compiler and/or linker running out of memory, but I have the latest version and still hit those errors.

I guess I’ll just go back to VS2017. Life was easier.