After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 751204 - osx: duplicate dylibs are distributed with both -devel and -runtime installed
osx: duplicate dylibs are distributed with both -devel and -runtime installed
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: cerbero
git master
Other Mac OS
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
: 755273 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2015-06-19 09:19 UTC by Heinrich Fink
Modified: 2018-11-03 10:19 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Heinrich Fink 2015-06-19 09:19:30 UTC
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.
Comment 1 Heinrich Fink 2015-06-19 12:01:50 UTC
In my own packager (which is a very simple subclass of DistTarball, we only need the OSX libs/headers in a simple layout), I could fix this by replacing shutils.copy with something simple like this: 

if os.path.islink(in_path):
    linkto = os.readlink(in_path)
    os.symlink(linkto, out_path)
else:
    shutil.copy(in_path, out_path)

Note that in Python 3.4 there is a call shutil.copyfile with follow_symlinks = True. 

And the tarball packaging nicely keep symlinks alive now. This solves my problem. I tried doing similar modifications in the cerbero/packages/osx/packager.py (there were numerous shutil.copy calls which would have ignored the symlinks and copy them as files), but this doesn't seem to be enough, and for now I have given up since the simpler solution works for me now. I guess what would be missing is to teach the scripts of the packager to keep symlinks. No idea how to do that.
Comment 2 Daniel Macks 2015-06-22 08:13:33 UTC
Is this the same as Bug #735963?
Comment 3 Sebastian Dröge (slomo) 2015-06-22 09:48:32 UTC
Should probably just ship the symlinks with the runtime package too then. And hope that they don't get converted to copies during packaging...


(In reply to Daniel Macks from comment #2)
> Is this the same as Bug #735963?

No, the problem there is that someone didn't install the runtime package together with the devel package.
Comment 4 Sebastian Dröge (slomo) 2015-06-22 10:10:11 UTC
... or just what you describe above for creating links instead of copying.
Comment 5 Jan Schmidt 2015-09-21 03:26:29 UTC
We should do this the way Heinrich describes, with the devel package adding links for libgstaudio-1.0.dylib -> libgstaudio-1.0.0.dylib so that both apps and plugins end up linking against the fully version libs. Redistribution packaging should just then take the fully-version lib.
Comment 6 Sebastian Dröge (slomo) 2015-09-21 08:20:30 UTC
So let's do that? Jan, did you already look into what would be required for that and where to change things?
Comment 7 Sebastian Dröge (slomo) 2018-05-04 13:29:01 UTC
*** Bug 755273 has been marked as a duplicate of this bug. ***
Comment 8 GStreamer system administrator 2018-11-03 10:19:24 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/cerbero/issues/18.