I just noticed after building the juce demo plugin(linux) that it’s a whopping 8mbs. Almost 16 when built with the debug config. How does one go about reducing the size?
Compile with -ffunction-sections -fdata-sections , and then link with the --gc-sections flag, that will strip dead code and you should obtain a smaller binary.
Thanks, I’ll try that.
Interesting tip - does it really make a big difference? If so, perhaps I should be using those flags in the jucer-generated projects?
When using the juce_amalgamated files yes that makes a big difference because the default “granularity” for stripping dead code is at the file level – these options instruct the compiler to use a granularity at the function level. The similar option for macos is -dead_strip but I think xcode enables it be default. So yes you should try to put them in jucer generated files, that is worth trying.
Another nice option for linux is the “-Wl,–as-needed” which tells the linker to drop any unused shared library, so that they don’t show up anymore when you do a “ldd you_program”
I just tried those flags for compiling the jucer, and it made absolutely no difference whatsoever! The exe was exactly the same size, not even a single byte smaller!
Strange. Did you use “-Wl,–gc-sections” at the link stage ? (I forgot to mention the --Wl in my original post, it is required since the --gc-sections option is for the linker, not the compiler)
I’m using xcode, and added those options to the extra link stage - I tried with the -Wl and it came back saying that --gc-sections was an unknown option. Do you think it’s not available in gcc 4.2?
Oh sorry, It is linux-only. Or maybe restricted to the gnu linker, I’m not sure. Anyway , it does not work on macos, but I think it may also work on windows when using mingw.
However it is much simpler on mac, just add a “-dead_strip” at the link flags and you’re done. But I think that xcode already does that by default. There is also a “-dead_strip_dylibs” that is equivalent to the “-Wl,–as-needed” that I mentioned later.
Ah, I see. I’d assumed that it was a generic gcc thing. Ok, thanks!