[Bug 762140] New: osx: use relative linker paths

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=762140

            Bug ID: 762140
           Summary: osx: use relative linker paths
    Classification: Platform
           Product: GStreamer
           Version: git master
                OS: Mac OS
            Status: NEW
          Severity: normal
          Priority: Normal
         Component: cerbero
          Assignee: gstreamer-bugs at lists.freedesktop.org
          Reporter: hfink at toolsonair.com
        QA Contact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---

There is often the need to bundle GStreamer into some other OSX bundle
(framework or app). For this to work we have to use relative linker paths for
all GST libs and also plugins. 

At my company we achieved this through a (sort of hack-ish) custom cerbero
tarball packager that just brute-force runs install_name_tool over all binaries
before packing them into a tarball (not nice, but works, see
http://paste.debian.net/hidden/a3156b37/, start reading at line 227). Ideally,
the OSX (and iOS?) build-chain would deal with that earlier (maybe as libtool
args so it could also be used for gst-uninstalled on OSX?), and IMO we should
make this the default mode to build on OSX.

I will explain how we currently use a combination of @loader_path and @rpath to
make this work. man dyld (i.e. @rpath and @loader_path) provides the background
knowledge.

So this is how it currently looks like (I am shortening the output, i.e.
skipping dependencies with similar/non-relevant paths to make this more
concise):

otool -L bin/gst-inspect-1.0 
gst-inspect-1.0:
    /System/Library/Frameworks/CoreFoundation.framework/CoreFoundation
(compatibility version 150.0.0, current version 1241.11.0)
    @rpath/libgstreamer-1.0.0.dylib (compatibility version 701.0.0, current
version 701.0.0)
        <skipping rest>

Now, gst-inspect-1.0 also has an rpath entry of "@loader_path/../lib", so when
loading the library, dyld can find libgstreamer-1.0.0.dylib in the lib folder.

If you look at 

otool -L lib/libgstreamer-1.0.0.dylib 
lib/libgstreamer-1.0.0.dylib:
    @rpath/libgstreamer-1.0.dylib (compatibility version 701.0.0, current
version 701.0.0)
    @rpath/libgobject-2.0.0.dylib (compatibility version 4601.0.0, current
version 4601.2.0)
        <skipping rest>

you will see that we also use @rpath here, and libgstreamer-1.0.0.dylib has an
rpath set to @loader_path, so it can find its dependencies residing in the same
folder.

For plugins, it looks like this:

otool -L lib/gstreamer-1.0/libgstcoreelements.so 
lib/gstreamer-1.0/libgstcoreelements.so:
    @rpath/libgstbase-1.0.0.dylib (compatibility version 701.0.0, current
version 701.0.0)
        <skipping rest>

We could also add an @rpath to each plugin to load from @loader_path/../lib,
but @rpath's accumulate over the dependency chain, so this might not be
necessary (we haven't, but probably should be done to be consistent). The whole
point of @rpath is that - depending on your application/framework's layout -
you can add multiple rpath that each will be used for an attempt to resolve a
dependency. Setting DYLD_PRINT_RPATHS=1 can help to debug problems here (see
man dyld).

So that's our story. If I'm not mistaken, the above approach applied earlier in
the build process could automatically make the OSX frameworks re-locatable as
well. And since iOS also supports dynamic linking for a while now, this might
be useful there as well. Any ideas at which point this whole
@rpath/@loader_path should best be applied to be as much re-usable as possible?

caveats: setuid process usage is prohibited on OSX when relative linker paths
are used (e.g. the ptp-helper process shipping with GStreamer)

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.