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