Linking a static library hierarchy in projucer

Windows
1

Hi everyone,

apologies if this has been mentioned already. I had a query re linking static libraries in a JUCE project.

I have two Visual Studio C++ projects, A and B, that both compile into static libraries (no dependency on JUCE, just C++ stuff); B depends on A. Some context:

  • Project A contains MIDI functions
  • Project B contains (MIDI-related) functions for a specific hardware synthesiser and uses A’s functionalities.

Both projects compile fine. I can also create a non-JUCE VS solution, import the above libraries and compile a working application.

I’m trying to figure out the correct settings for importing projects A and B in a Projucer project. So far, I’ve found different suggestions in previous posts here in the forum e.g., some suggest to include the .lib extension, others omit it on purpose.

In Projucer’s Extra Compiler Flags, Extra Linker Flags, and External Libraries to Link boxes, I’ve added the following:

-I$(ProjectDir)..\..\..\libA\libA\src
-I$(ProjectDir)..\..\..\libB\libB\src

-LIBPATH:$(ProjectDir)..\..\..\libA\bin\$(Platform)\$(Configuration)\
-LIBPATH:$(ProjectDir)..\..\..\libB\bin\$(Platform)\$(Configuration)\

libA
libB

When compiling, VS complains that

1>LINK : fatal error LNK1104: cannot open file 'libA.obj'

Since both libraries A and B are in continuous development, I’m particularly interested in adding references to A and B in the JUCE application (so that I can edit all three projects simultaneously if needed). Is this possible?

Any help much appreciated!

2

Solved. I changed the Runtime Library setting to match across all projects.

Visual Studio libA and libB projects have the following settings under Properties > Configuration Properties:

  • General > Configuration Type: Static Library (.lib)
  • C/C++ > Code Generation > Runtime Library: Multi-threaded Debug (/MTd) and Multi-threaded (/MT) for Debug and Release configurations respectively.

For the Projucer project, Exporters > Visual Studio 2019:

  • External Libraries to Link: libA.lib, libB.lib
  • Debug/Release > Runtime Library: Use static runtime.

One advantage is, I didn’t have to import any C++ header/source or precompiled lib files in the Projucer source directory; I just added include paths in Projucer’s Header Search Paths, and Extra Library Search Paths.

Hoping this will be of help to someone.

3

Thank you, this was a helpful reminder to correctly set that Projucer field. I’ll add to it the caveat from the Projucer help, “if you are linking libraries from different sources you must select the same type of runtime used by the libraries”… which means you cannot mix and match static and dynamic external libraries in a given project.

There’s another possible gotcha that can trip up Visual Studio and cause that Linker Error LNK1104 (“cannot open file filename”), and that is spaces in the filepath. As the Microsoft error page says, the cause might be that “your library paths are incorrect, or aren’t wrapped in double-quotes.”

I was adding a JUCE module I had made to a project, and that module included a static external library via the module’s windowsLibs directive. The full filepath for the library files did include a space, and unfortunately, that was causing that linker error LNK1104 to appear.

The workaround was after exporting from Projucer to VisualStudio, and in the Configuration dialog for each target (AAX, VST3, Standalone), under Linker → Input → Additional Dependencies, to replace the simple mylib.lib entry with the full filepath, in double quotes.

4

As a followup, I then changed the directory names on disk, to remove any spaces in the filepath to the static library. That time, VisualStudio built the project - without me having to go into Linker → Input → Additional Dependencies and put the full file path inside double quotes.

So there seems to be some issue with how precompiled library filepaths are passed from Projucer to VisualStudio, but where the fault lies or whose bug is responsible, I couldn’t say.

5

The issue comes from Projucer, which splits the value associated with windowsLibs on commas and spaces:

6

Ah, thanks for finding that. Perhaps this is cause for a note to be added to the JUCE module documentation, to avoid this little caveat from tripping up others.

Though to be clear, there was no linker error when building the project in Xcode. This was only a problem with VisualStudio.