How to use a dylib in a plugin with Projucer?

General JUCE discussion
1

Hi folks !

I want to use Sentry in my plugin and I need to use a .dylib and an executable (crashpad_handler).

I’ve never use this kind of library and I wasn’t able to find any beginner tutorial.

What should I set in the Projucer project to use it correctly ?

So far, I do the following actions:

  • added the .dylib as an “Xcode Resource”
  • set sentry in the External Libraries to Link
  • set mypath/sentry/include in the Header Search Paths
  • set mypath/sentry/lib in the Extra Library Search Paths (but not sure if this one is needed)

How do you setup your Projucer project to use a .dylib in a plugin ?

Thanks

2

This post might be of help:

3

Thanks @Cymatic !
I manage to make it works thank to this

1 Like
4

Greets, @Cymatic!

I want to play with phonon too, but no matter how I dance with a magic tambourine around it, I can’t connect the library in Xcode to a. cpp, building result is “Library not found for -l/usr/local/lib/” in any combination i’ve tried

Since you are successful with it i’d like to ask you a few questions

-SteamAudio SDK version for that successful project?
-OS/Xcode version?

are below options applied correctly by mine?

  • libphonon.dylib is copied into /usr/local/lib/

  • in source .cpp = #include <phonon.h>

  • extra library search path (producer exporters Debag and Release)
    = /usr/local/lib/

  • external libraries to link (producer exporters Xcode
    = /usr/local/lib/libphonon.dylib

have i to include any lines somewhere else or copy something to somewhere else?

5

If you’re using little-l “-l” in this flag, this means you are trying to link to a library called “/usr/local/lib/”, which is a path, not a library. If your intention is to use that as a path to find libraries, the correct flag is big-L “-L”, to set /usr/local/lib/ as a path in which to search for libraries. (This might just be a typo on your part in composing your message, but just in case its not, you’d definitely need to fix this..)

Then, to link to “libphonon.dylib”, you’d add “-lphonon” as an option - with these two flags properly set, you’d be telling the linker to search /usr/local/lib for a library named phonon, which it will automatically convert to mean the file named “libphonon.dylib”.

So - first - be sure your linker flags are set thus: “-L/usr/local/lib/ -lphonon” ..

However, since this is a dynamically loaded library (.dylib), you must also set the runtime path for library loading so that libphonon.dylib is bound with your application image at runtime. (You would also need to ship the library and put it in /usr/local/lib/ .. but once you get this working for development, you can work out how to package libphonon.dylib in your projects’ own bundle directory, which is another can of worms..)

You set this runtime linker flag with the -rpath option (as mentioned previously), so for example:

gcc -o myprogram myprogram.c -L/usr/local/lib/ -lphonon -Wl,-rpath,/usr/local/lib/

If you’re using Projucer to configure your project, you add this string to the “Extra Linker Flags” section:

-Wl,-rpath,/usr/local/lib/
  • but be sure to also add the “phonon” identifier to the “External Libraries to Link” field - as both are needed to make this work.
6

the detailed exact recommendation, @ibisum! it worked! thank you!

One context question has appeared, please…

when a juce plugin with a dynamic lib included is loaded into a DAW, does it access while addressing later to the library’s data on ssd/hdd physically or copies the library into the RAM first and after that takes all lib’s data needed from there? Or does it depend on any special pre-build settings?

7

I would suggest you read the docs, just a little bit - it won’t hurt:

(See the equivalent docs for Windows/Linux - not sure if you have access to developer.apple.com, but I assume you do..)

Dynamic libraries are typically loaded into RAM by the operating system when the plugin is loaded into the DAW. The library’s code and data are mapped into virtual memory, with pages loaded into physical RAM on-demand as they are accessed. The library file on the SSD/HDD is not repeatedly accessed during execution; once a memory page is loaded into RAM, it stays there for fast access unless swapped out by the OS (rare for real-time applications like plugins).

Pre-build settings (e.g., static vs. dynamic linking, embedded resources, or explicit file I/O) can influence whether the plugin accesses disk-based resources or relies entirely on RAM. If the plugin explicitly reads external files (e.g., samples or presets), those accesses may hit the SSD/HDD unless cached by the OS.