gst-plugin-scanner creates problem with @executable_path on macOS
I'm trying to deploy a portable gstreamer application, which uses some custom plugins. Currently I'm facing dynamic linking issues when loading my custom plugins. My assumption is, that this is because Gstreamer uses a child process executable (gst-plugin-scanner) to load plugins. This in turn messes with the @executable_path variable I use in my custom plugin. But lets start from the beginning:
Let's say my file structure after installation looks like the following:
|- bin
|- my-executable
|- lib
|- gstreamer
| - my-custom-plugin.dylib
|- my-custom-library.dylib
my-executable
depends on my-custom-library.dylib
. Hence, it includes something like @rpath/my-custom-library.dylib
for this lookup and my-executable
's rpath is set to @executable_path/../lib
. As a result, at load time, the linker will search for my-custom-library.dylib
in <full_path_to_my_executable>/../lib
. So far so good, this works flawlessly as @executable_path
is replaced with the full path to my executable at runtime.
Now, my-custom-plugin
also depends on my-custom-library.dylib
so I added the similar settings as above. The idea is that all my shared libraries reside in the lib
folder on distribution. However, when Gstreamer tries to load my-custom-plugin
as runtime, I get a linker error dlopen(<full_path>/lib/gstreamer/my-custom-plugin.dylib, 2): Library not loaded: @rpath/my-custom-library.dylib Reason: image not found
.
What the linker is telling me is that it can't find my-custom-library.dylib
at @executable_path/../lib
which leads me to the assumption from above (i.e. that the fact gstreamer calls the gst-plugin-scanner
alters the value of @executable_path
which in turn breaks the library lookup).
My questions would be:
- Is this a known issue?
- If so, is there any known workaround?
- Is there a way to not use the external
gst-plugin-scanner
executable?
P.S.: Please not that I know I could use @loader_path/../
, which would replace @loader_path
with the directory of my-custom-plugin.dylib
as runtime. However, this is nor really portable because if another directory for the Gstreamer plugins would be used, the path would no longer point to the right directory.