GNOME Bugzilla – Bug 751204
osx: duplicate dylibs are distributed with both -devel and -runtime installed
Last modified: 2018-11-03 10:19:24 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.
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.
Is this the same as Bug #735963?
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.
... or just what you describe above for creating links instead of copying.
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.
So let's do that? Jan, did you already look into what would be required for that and where to change things?
*** Bug 755273 has been marked as a duplicate of this bug. ***
-- 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.