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 727534 - cerbero: Add support for non-standard Darwin .dylib filenames
cerbero: Add support for non-standard Darwin .dylib filenames
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: packages
unspecified
Other All
: Normal normal
: 1.3.1
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2014-04-03 11:10 UTC by Philip Withnall
Modified: 2014-04-07 12:35 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
filesprovider: Add support for non-standard Darwin .dylib filenames (2.66 KB, patch)
2014-04-03 11:10 UTC, Philip Withnall
committed Details | Review

Description Philip Withnall 2014-04-03 11:10:51 UTC
As explained in the patch commit message, Cerbero currently expects dynamic libraries to be named ‘libfoo.[0-9]+.dylib’, whereas they can actually also be named ‘libfoo.dylib’. The patch fixes that.
Comment 1 Philip Withnall 2014-04-03 11:10:53 UTC
Created attachment 273519 [details] [review]
filesprovider: Add support for non-standard Darwin .dylib filenames

Conventionally, dynamic libraries are named ‘libfoo.[0-9]+.dylib’ on
Darwin. It is possible, however, for one to be named ‘libfoo.dylib’
without the library version.

Add support to filesprovider for this non-conventional naming scheme,
fixing runtime package builds for projects with these non-conventional
libraries.
Comment 2 Sebastian Dröge (slomo) 2014-04-03 19:02:03 UTC
commit cf44849261ec616fb8b10f5a983c7317c5af07f9
Author: Philip Withnall <philip.withnall@collabora.co.uk>
Date:   Wed Apr 2 12:55:26 2014 +0100

    filesprovider: Add support for non-standard Darwin .dylib filenames
    
    Conventionally, dynamic libraries are named ‘libfoo.[0-9]+.dylib’ on
    Darwin. It is possible, however, for one to be named ‘libfoo.dylib’
    without the library version.
    
    Add support to filesprovider for this non-conventional naming scheme,
    fixing runtime package builds for projects with these non-conventional
    libraries.
    
    https://bugzilla.gnome.org/show_bug.cgi?id=727534
Comment 3 Andoni Morales 2014-04-03 22:17:58 UTC
I am not sure this patch is completely correct as .dylib libraries are the libraries used at link time, similar to libfoo.so files in linux.
The problem with this patch is that libfoo.dylib libraries that are now treated as link libraries and packaged in the development packages will be also packaged in the runtime package.
Can you please describe the project creating this kind of library?
I think the correct fix is in the recipe's post-install step, moving libfoo.dylib to libfoo.0.dylib and link libfoo.dylib to libfoo.0.dylib.
Comment 4 Andoni Morales 2014-04-03 22:35:07 UTC
Or even better, fix it upstream so that the linker creates a versioned library and not a module
Comment 5 Philip Withnall 2014-04-04 07:47:28 UTC
(In reply to comment #3)
> I am not sure this patch is completely correct as .dylib libraries are the
> libraries used at link time, similar to libfoo.so files in linux.
> The problem with this patch is that libfoo.dylib libraries that are now treated
> as link libraries and packaged in the development packages will be also
> packaged in the runtime package.

Looking at the output packages I have here, the dylib has been put in the runtime package and not the development package. That makes sense to me. It’s needed at runtime for dynamic loading, and also needed at development time — but it seems to be entirely reasonable to require the developer to have both the development and runtime packages available to compile against.

The patch does exactly the same for .dylibs as is already implemented for Windows DLLs.

> Can you please describe the project creating this kind of library?
> I think the correct fix is in the recipe's post-install step, moving
> libfoo.dylib to libfoo.0.dylib and link libfoo.dylib to libfoo.0.dylib.

The project doesn’t have an SO version (or its Darwin equivalent) set. Unfortunately, that naming on the library is a requirement of the project, so can’t be changed. Otherwise we would have done that already. :-(
Comment 6 Andoni Morales 2014-04-05 11:46:27 UTC
(In reply to comment #5)
> (In reply to comment #3)
> > I am not sure this patch is completely correct as .dylib libraries are the
> > libraries used at link time, similar to libfoo.so files in linux.
> > The problem with this patch is that libfoo.dylib libraries that are now treated
> > as link libraries and packaged in the development packages will be also
> > packaged in the runtime package.
> 
> Looking at the output packages I have here, the dylib has been put in the
> runtime package and not the development package. That makes sense to me. It’s
> needed at runtime for dynamic loading, and also needed at development time —
> but it seems to be entirely reasonable to require the developer to have both
> the development and runtime packages available to compile against.
> 

The problem is not with your particular library but with the rest of them that uses the regular naming scheme. At runtime libfoo.dylib is not needed since the runtime linker will use libfoo.x.y.z.dylib (check for instance the output of any library with otool -L), that's why we put them in the devel packages. With your patch libglib-2.0.dylib will be both in the development package and the runtime package which is wrong from a packaging point of view.

> The patch does exactly the same for .dylibs as is already implemented for
> Windows DLLs.

It does not do the same thing as in Windows, because in Windows both bin/libfoo.dll and bin/libfoo-1.dll are runtime libraries and the link libraries are in lib/libfoo.dll.a and lib/libfoo.lib.

> 
> > Can you please describe the project creating this kind of library?
> > I think the correct fix is in the recipe's post-install step, moving
> > libfoo.dylib to libfoo.0.dylib and link libfoo.dylib to libfoo.0.dylib.
> 
> The project doesn’t have an SO version (or its Darwin equivalent) set.
> Unfortunately, that naming on the library is a requirement of the project, so
> can’t be changed. Otherwise we would have done that already. :-(

Since yours is a special case, you can't modify the packaging rules for the rest of regular uses cases. If your library don't use the default naming scheme for libraries do not use the default libs category. You can use something like

platform_files_libraries = {Platform.DARWIN: ['lib/libfoo.dylib']}
Comment 7 Philip Withnall 2014-04-07 11:51:26 UTC
(In reply to comment #6)
> (In reply to comment #5)
> > (In reply to comment #3)
> > > I am not sure this patch is completely correct as .dylib libraries are the
> > > libraries used at link time, similar to libfoo.so files in linux.
> > > The problem with this patch is that libfoo.dylib libraries that are now treated
> > > as link libraries and packaged in the development packages will be also
> > > packaged in the runtime package.
> > 
> > Looking at the output packages I have here, the dylib has been put in the
> > runtime package and not the development package. That makes sense to me. It’s
> > needed at runtime for dynamic loading, and also needed at development time —
> > but it seems to be entirely reasonable to require the developer to have both
> > the development and runtime packages available to compile against.
> > 
> 
> The problem is not with your particular library but with the rest of them that
> uses the regular naming scheme. At runtime libfoo.dylib is not needed since the
> runtime linker will use libfoo.x.y.z.dylib (check for instance the output of
> any library with otool -L), that's why we put them in the devel packages. With
> your patch libglib-2.0.dylib will be both in the development package and the
> runtime package which is wrong from a packaging point of view.

Ah, I didn’t clock that this would cause libfoo.dylib to end up in the runtime package for normal projects.

> > > Can you please describe the project creating this kind of library?
> > > I think the correct fix is in the recipe's post-install step, moving
> > > libfoo.dylib to libfoo.0.dylib and link libfoo.dylib to libfoo.0.dylib.
> > 
> > The project doesn’t have an SO version (or its Darwin equivalent) set.
> > Unfortunately, that naming on the library is a requirement of the project, so
> > can’t be changed. Otherwise we would have done that already. :-(
> 
> Since yours is a special case, you can't modify the packaging rules for the
> rest of regular uses cases. If your library don't use the default naming scheme
> for libraries do not use the default libs category. You can use something like
> 
> platform_files_libraries = {Platform.DARWIN: ['lib/libfoo.dylib']}

I contend that this is a special case: it will happen for any library which doesn’t specify a SO version. Still, if you feel that’s sufficiently special, please revert my patch (I don’t have commit rights on the repository).

Thanks for the workaround. We’ll use that for now.
Comment 8 Andoni Morales 2014-04-07 12:35:14 UTC
We are packaging near 100 libraries and this is the first one that doesn't follow the pattern, so I'd say it's a special case :)

commit 020b5b55d69b4f27c744127d72a76068a058143b
Author: Andoni Morales Alastruey <ylatuya@gmail.com>
Date:   Mon Apr 7 14:34:33 2014 +0200

    Revert "filesprovider: Add support for non-standard Darwin .dylib filenames"
    
    This reverts commit cf44849261ec616fb8b10f5a983c7317c5af07f9.