Duplicate symbols when linking against static Juce library

Hey there,

I have been building a static library with Juce which I want to use in another Juce application. Everything has worked out fine so far but now I’m facing the following problem:

When I compile the library in release mode and want to link against it when compiling the Juce apllication in debug mode I get the error:

ld: 2116 duplicate symbols for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

The duplicate symbols are found in the Juce modules.
When I compile both the library and the application in release or both in debug everything works out fine.

However there are reasons to have the library as a release build and compiling the application in debug:

  • The library performs some heavy computations and as a debug build it is incredibly slow.
  • Eventually the library and the contained algorithms should be delivered to a client without him being able to see the source code. As a compiled debug library it would still be possible to step through the code with a debugger.

I am working on Mac OS using Xcode.

How can I resolve this duplicate symbol issue?

Looking forward to hearing some hints!

I have fixed the duplicate symbols issue by explicitly excluding all juce modules when compiling the library (unchecking Target Membership in Xcode).
But now I get another error wehen compiling the app in Debug mode:


Looks like it really doesnt work to include a release built library in a debug build of my application. Is there any workaround to fix this?
Or other ideas how to debug the main application and still have the library run at “release build speed”?

I imagine if you were to set NDEBUG=1 and to undefine both DEBUG and _DEBUG in the preprocessor definitions of your executable target, you should be able to avoid this error. In fact, you should probably ensure that all your preprocessor defines are identical between the static lib and the executable - having differently-preprocessed headers may lead to weird link errors (like this one) or possibly runtime crashes.