JUCE dependent static library

Hello,

I’m working on a project that uses the JUCE framework, and the previous team implemented some functionality based on JUCE. I’ve created other projects reusing that code, but now I have a task to turn that code into a static library so that other teams outside the company can use it in their own JUCE projects.

I’m facing issues when trying to link it as a static library to my project. I keep getting an error about function redefinition when linking, specifically related to include_juce_core.obj in the static library and juce_core.obj in the new test plugin. I’m not sure where the include_*.obj comes from.

Is it possible to compile a static library that other projects can use without needing the source code?

Would this be achievable through module development? I’ve tried it but I’m unsure how to compile it within the module structure.

If you have any resources or advice, I’d really appreciate it.

Thanks,
A.

I keep getting an error about function redefinition when linking, specifically related to include_juce_core.obj in the static library and juce_core.obj in the new test plugin.

This implies that you are including JUCE code in the modules which constitute your library - in order to debug this properly you must pay closer attention to what functions are being reported in both your library and the official JUCE framework - not just to solve your problem, but also to be absolutely sure that you are complying with the JUCE license - because it appears, so far, you are not.

Is it possible to compile a static library that other projects can use without needing the source code?

Technically, yes of course - but legally, no, you’d be violating the License terms which you agree to by using the JUCE framework. You cannot ship JUCE code as if it were your own.

Separate your code: stuff you/your team wrote and own, and stuff that was included as a part of using JUCE in your project. Build the library containing only your own code, and inform your end-user/developers that they must also include the JUCE framework as a dependency of your library. This allows you to ship your own special code and as well, comply with the JUCE license terms.

So, there aren’t any already include mechanisms allowing it do it legally, like using a proxy or something similar, that would allow me to avoid including JUCE modules and only use them under a JUCE license from external companies using juce? I mean, it looks to be just using threads, XML readers, and JUCE data types. In theory, I could port it, but the idea was to avoid that. However, in terms of licensing, it seems like a better idea to port it to a JUCE-free library if they want to use it outside the company, right?

Thanks for your support.

This setup is definitely permitted by the JUCE license, as long as the users of your library know that it uses JUCE internally, and adhere to the appropriate JUCE license terms.


It sounds like your goal is to distribute a compiled binary, rather than source code, perhaps in order to prevent theft of IP.

It can be difficult to distribute C++ static libraries in a way that’s easy for clients to incorporate, especially if those libraries use C++ types/functions in their interfaces. Mismatches in compiler version, compiler flags, and standard library version makes it easy to accidentally introduce ODR violations (undefined behaviour) and/or ABI mismatches. If the library were to use JUCE types in its interface, this would add another set of variables (JUCE version and all preprocessor flags) that would need to be identical between the static library and clients of that library.

If possible, I’d recommend wrapping the C++ library in a plain C interface, and building it as a dynamic library with all symbols hidden other than the C entry points. Providing a C interface allows the use of the C ABI, which is much more consistent across compilers than the C++ ABI, and therefore will allow users of the library to use different compilers, compiler versions, and compiler flags. Hiding all symbols other than the library entry points will prevent ODR violations from mismatched standard library and JUCE versions.

2 Likes