[Bug 751204] New: osx: duplicate dylibs are distributed with both -devel and -runtime installed

[GStreamer (GNOME Bugzilla)]

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

            Bug ID: 751204
           Summary: osx: duplicate dylibs are distributed with both -devel
                    and -runtime installed
    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: ---

When building an application using Xcode that directly links to GST libs using
linker flags like "-L/PATH/TO/GStreamer.framework/Libraries -lgstaudio-1.0",
Xcode will link to (e.g.) libgstaudio-1.0.dylib. However, plugins are linked
against libgstaudio-1.0.0.dylib, and this will cause the application to load
libgstaudio twice, resulting in confusing errors of the type registration
system (causing errors like "
(<unknown>:8918): GLib-GObject-WARNING **: cannot register existing type
'GstObject'", and then weird other errors).

The problem is that installing the -devel package adds another hard copy of
libgstaudio (and other libs), resulting in two copies of the lib: 
libgstaudio-1.0.0.dylib and libgstaudio-1.0.dylib. But instead it should
actually keep a symlink from libgstaudio-1.0.dylib -> libgstaudio-1.0.0.dylib.

I have noticed this while writing a custom OSX packager in cerbero (in our
applications we have other lib layouting requirements than the standard
framework). Then I tested this with the current 1.5.1 precompiled OSX
installers to confirm that this seems to be a general problem.

I am not sure yet where the problem originates and how this should be solved
properly. My current best guess is that in cerbero "devel" files include
*.1.0.0.dylib's and runtime files only include *.1.0.dylib files, and some
copying phase doesn't keep symlinks but instead creates separate files.

If I step onto something obvious, I'll try posting patches here, but maybe
someone else has advice/an idea on where to start looking?

Note that this bug is related to #735963.

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