Hi,
I’m trying to link a .dylib for an audio plugin Projucer project. It works fine for a GUI project though.
I’ve set the .dylib relative path in Embedded Frameworks under the Xcode exporter. Additionally, I’ve set the path to the .dylib under Extra Library Search Paths in the configuration section (I did the same for a GUI project and it worked fine there).
I’m getting two errors when compiling the audio plug-in project:
-
When compiling the VST3 target, I’m hitting this error Multiple commands produce '[path to.dylib]'. Targets - Shared Code has Copy command from ..... Targets - VST3 Manifest Helper has Copy command from ...
-
When compiling the Standalone Plugin target, I’m hitting this error after Xcode tries to codesign: [path to.app]: code object is not signed at all In subcomponent: [path to .dylib]. I have not specified anything regaring codesigning in the jucer file, this is the default Xcode signing for local running.
(I’ve stripped away some things from the error output, but I hope it’s clear enough).
Could this be an Xcode or JUCE bug or am I missing something?
Xcode 16.2
JUCE 8.0.6
Compiling on macOS Apple Silicon (M1) for “My Mac”.
Thanks,
Jelle
Update
I can get it compiling if I manually enable “Code Sign On Co…” for the .dylib under Embed Frameworks in Xcode and additionally remove the .dylib for the VST3 Manifest Helper target under embed Frameworks in Xcode.
Loading dynamic libraries in this way is quite difficult to do for plugins.
If you can, I would suggest to instead use juce::DynamicLibrary and load/cast the functions at runtime. In that way the build system doesn’t need to know about the specifics of the library, and this can work really well from within a plugin or a standalone app.
See example here:
Thanks @eyalamir for sharing your insights.
In my case the DLL is for a third party library I’m using. So, I’m not very much concered with the details on how to call the DLL functions. I’m concerned with how the DLL (and dylib on macOS) is shipped and linked with, currently focussing on macOS to get started with. I understand that on macOS the .dylib should be placed under the Frameworks folder within the application or plugin bundle. I’m trying to set this up in Projucer so that the .dylib is automatically copied to that directory.
Do you have any insights about how to configure the jucer file to link properly?
Perhaps I’m doing this completely wrong and I should just put the .dylib under a specific folder under Application Support and just point JUCE to there…?
If you use DynamicLibrary, the app doesn’t need to specify anything about how to link with the external library.
There’s some manual-ness in casting the functions (you can’t call functions in the 3rd party headers directly) but it would allow you to load those external libs correctly from a plugin, and it would work in any DAW and in any OS.
1 Like
My main problem is that I don’t know how to deploy the dynamic library properly. I’ve explained that for macOS apps the .dylib usually is placed in the framework folder. I cannot get this to work properly with the Projucer. This currently is my main issue.
With the DynamicLibrary approach the library can be anywhere - if you look at the example I posted above I use juce::File - using that method the dll doesn’t have to be at a specific location - it’s very similar to how you would load a VST3 for example.
@eyalamir
What is the reason I cannot or should not use the (in my opinion) “normal” .dylib approach like I described? Why would you prefer the juce::DynamicLibrary ?
I just don’t think a regular dll can work from a plugin that’s loaded in a DAW that runs on another process. Maybe there’s a way to do it in some hosts/OSs but I don’t think it would work reliably.
A DynamicLibrary does work across all platforms/hosts from within a plugin.
1 Like
Okay thanks!
For context, it was about the ONNX runtime library from Microsoft. But I’m gonna give static linking a try as suggested in ort-builder: GitHub - olilarkin/ort-builder: ONNX Runtime static library builder
