JUCE - avoiding LNK1248 - structuring Windows builds

Hi all,

Something I’ve been meaning to share for a long time, and it is Sunday so I have a little time to share!

Basically, my code base is large. So large, that if I were to build it for Windows as a straight-ahead project, I get LNK1248, e.g.:

fatal error LNK1248: image size (blah) exceeds maximum allowable size (FFFFFFFF)

Interestingly, I first started seeing these error codes appear with debug builds, before I started seeing them with release builds.

I found those errors even when using Visual Studio 22 with a 64-bit toolchain.

My solution has been to divide-up my code into a number of static libraries:

Static Library for App 1 - my code
Static Library for App 2 - my code (even more of it)
Static Library for App J - the JUCE code
App - this is pretty minimal, just a main.cpp

For my convenience, when building VST3, I have separate copies with completely different target rules caused by the need to use multi-threaded DLL flags

Static Library 1 for VST3 - my code
Static Library 2 for VST3 - my code etc.
Static Library J for VST3 - the JUCE code
VST3 - this is pretty minimal, just the code adaptor layer appropriate for VST3 (Processor, Editor).

Furthermore, because I build for ARM64 as well as x64, all the above target both x64 and ARM64.

Because of my special requirements, I maintain all the project files manually.

Hoping this helps somebody out there!

Best to all, Pete

1 Like

Wow, that’s a lot more than 640K!

2 Likes

Wotja is more than 500 thousand lines of code - excluding JUCE :slight_smile:

Is this all user-created code or is some of it auto-generated (like JuceLibraryCode/BinaryData.cpp)?

Hi @yairadix, that is all “real code” - not binary data. :slight_smile:

Mind you, I’ve been working on the code base behind Wotja for over 30 years now, so it has kind of accumulated!

Pete

1 Like

Wow, that’s an even more impressive stat! So I’ll have to try it out, sounds very interesting!

1 Like

Wotja has even won a couple of BAFTA awards over the years (under older brand names - Koan, and miniMIXA). But still, few people seem to know about it! :wink:

Best wishes,

Pete

3 Likes

I love the samples on the site. I’ve been wondering about a good evolving soundscapes tool for a while! It sounds great; I’ll be checking it out.

1 Like

Hi @psyzza, thank you very much :slight_smile:

Best wishes, Pete

Hey I’m having the LNK1248 issue, but surprisingly this started happening after I split my code into several libs. And only happens in release build.

I think the lib sizes being generated are just very large and then when it trys to do some LTO it creates a massive image thats too large …

I’m wondering if anyone has any suggestions how to handle this?
My main thought is to disbale LTO flags, but then I assume I lose some benefit of a typical release build. But surely theres some other way to handle this? My project is big but not that big.

// -------------------------------------------------------------------------------

After doing more digging its definitely something to do with Whole Program Optimzation …

Its turning my super small file, usually a 8kb object into a 1mb obj on relase build with WPO on. I know release build can do some weird symbol optimzation stuff, but a 100x increase seems kinda crazy.

And then with ‘bigger’ files like juce_core it becomes a 10mb obj. Is this normal?

Hi @Wiznat I’m glad to hear that turning off WPO was a working solution for you - I’m not sure what else to suggest.

As Wotja - now up to Wotja 25! - is extended, I occasionally need to re-organise our Windows project files when LNK1248 appears. That doesn’t happen very often, thankfully.

Best wishes,

Pete