Static JUCE libraries in other C++ projects

Hey all,
I’m working on a senior design project for university, making a graphics renderer react to user input midi messages. We’re using SDL2 for our rendering engine / GUI, and Juce to handle midi events.
Our main editor that everyone is using is Sublime text, since we have 2 members on Mac, and 3 on PC. We’re running builds through the integrated command line there.

I’ve been able to make a console application to drive the header file that gets the necessary midi information, and turn it into standard C++ strings and such, so non-juce Code can make calls.

My plan was to make a static library (or dynamic, whatever works), and pass that to my PC devs, and have my Mac devs build there own version in Xcode, so that everyone gets the necessary OS specific midi libraries. So, here are my questions:

-do myLib.lib files work outside of Visual studio? both the Visual studio and the Codeblocks version of the static library project made with projucer build with .lib, and I was expecting a myLib.a file.

-For g++ command line args, I though -L directory would tell the linker to search and link in the specified directory, but I’m still getting errors asking for specific juce headers for each module.

-When those headers and module folders are included (which seems to defeat the purpose of the static library, maybe I’m not linking it correctly?), I get the error
"include/juce_core/system/juce_TargetPlatform.h:40:33: error: #include expects “FILENAME” or
40 | #include JUCE_APP_CONFIG_HEADER
| ^
This is after I throw #define JUCE_APP_CONFIG_HEADER in my JuceHeader.h file. It seems that I need some kind of list of other platform specific includes needed to build / link, but I can’t find anything in documentation about it.
If including regular non-static juce libraries can work with adding an extra file to list platform / OS specific dependencies, that might work better for our development than multiple static libraries floating around. Maybe?
At this point, I’d really just like this project to build.

Sorry for the long post, and what probably comes down to me having a incomplete understanding of how the g++ linker works. Let me know if there are any code snippets or anything that might give my issue a bit more clarity.

Running windows 10, with Visual studio 2019, Codeblocks, and sublime text. most recent versions of minGW pulled from the msys package manager.

Using JUCE as a static library is difficult, there have been many discussions around this forum throughout the years…

I will say, for any kind of cross platform set up, I 100% recommend CMake. It’s likely to yield much more stable/consistent results, and JUCE has native cmake integration.

2 Likes

Based on the description of your project, this won’t fly long. You should consider using a proper build system.


.a is the extension used for static libraries on Unix (including Linux and macOS).
.lib is the extension used for static libraries on Windows.


A pre-built library (whether it is static or shared/dynamic) frees you from distributing the source files (.c, .cpp, .cxx, etc.) but it doesn’t free you from distributing the header files (.h, .hpp, .hxx, etc.).
The linker works on object files (.o or .obj) and libraries (.a, .lib, .dylib, .so), but it doesn’t care about headers.
The compiler though needs to read the declaration of the types and functions. How would it know that juce::String exists otherwise?


The documentation is right in the code:


I hope this helps!

If you use JUCE in your library and the app/plugin linking your library use JUCE as well, you get in hells kitchen if they use only a slightly different version. That also includes only having a single preprocessor macro defined differently.

Also, I would very much recommend CLion as a cross-platform IDE, if you are going to go with CMake (which I also recommend).