GNOME Bugzilla – Bug 727534
cerbero: Add support for non-standard Darwin .dylib filenames
Last modified: 2014-04-07 12:35:14 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.
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.
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
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.
Or even better, fix it upstream so that the linker creates a versioned library and not a module
(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. :-(
(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']}
(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.
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.