Internal installation of GStreamer on Mac OS X

Alexey Chernov 4ernov at gmail.com
Mon Jul 22 14:57:39 PDT 2013


В письме от 22 июл 2013 12:40:44 Вы написали:
>  It's something that's not related to GStreamer but to way the dynamic
>  linker works in OS X. What needs to be fixed is the OS X relocator script
>  to use a different relocation technique, but using
>  DYLD_FALLBACK_LIBRARY_PATH is easy enough to integrate it in the start
>  script of the application.

Yes, DYLD_FALLBACK_LIBRARY_PATH is quite easy, but I think it could lead to 
some problems if there're both internal GStreamer version installed in app 
bundle and also another distribution of it installed in /Library/Frameworks 
which dyld attempts to use as primary search path. On the contrary, it's quite 
impossible to limit it with DYLD_FRAMEWORKS_PATH or so as it started to pick 
up some low-level libraries as libbz2 or libiconv from GStreamer distribution 
instead of system originals which also usually leads to crash.

I tried to change all the dependency paths for all of public GStreamer 
libraries (in Versions/Current/lib) to local @loader_path/<library.dylib> 
paths, all the dependency paths of plugins (in 
Versions/Current/lib/gstreamer-1.0) to local @loader_path/../<library.dylib> 
and also dependency paths of gst-plugin-scanner to local 
@loader_path/../../lib/<library.dylib> paths. And it started working with no 
problems either installed system-wide in /Library/Frameworks or internally in 
app bundle.

I think, it would be safe and useful to do it in future distributions 
(especially, -runtime and -packages variants) if it wouldn't have any side 
effects. It seems that it don't. I have a small script to change paths, I hope 
to post it to bugzilla as a feature tomorrow.


More information about the gstreamer-devel mailing list