Closed georgalis closed 1 year ago
What does every other library do?
The file extension on the Mac is a matter of convention, I think - .dylib
is used for libraries that are intended to be dynamically linked at link time so that the system's dynamic loader loads them automatically at runtime, and .so
for libraries that are intended to be loaded explicitly by the application at runtime.
The reason I remember this is because I used the wrong extension when working on audio processing plugins, and was a little embarrassed to discover it. Because such plugins are loaded explicitly at runtime using dlopen
, they should have .so
extension, but all the plugins I have worked on (e.g. Vamp plugins) have .dylib
. And as it turns out, this makes no difference in practice, which is why I didn't realise until it was too late.
Anyway, .dylib
is the "correct" extension on the Mac and also the extension that the Rubber Band build system uses as of right now, and changing it could break unknown other build systems. So there would have to be a very good reason!
On Tue, Mar 7, 2023 at 11:37 AM Chris Cannam @.***> wrote:
What does every other library do?
Yeah, I'm trying to figure that out, the answer might be it depends... but renaming to .so is probably not the best idea...
137
282
lrwxr-xr-x 1 geo staff 28 Mar 5 10:58 /opt/pkg-2022Q4/lib/libvamp-hostsdk.so -> libvamp-hostsdk.3.10.0.dylib lrwxr-xr-x 1 geo staff 32 Mar 5 10:58 /opt/pkg-2022Q4/lib/libvamp-sdk.so -> libvamp-sdk-dynamic.2.10.0.dylib #
this is a limited poc system, but so far it looks like anything is possible.
The file extension on the Mac is a matter of convention, I think - .dylib
is used for libraries that are intended to be dynamically linked at link time so that the system's dynamic loader loads them automatically at runtime, and .so for libraries that are intended to be loaded explicitly by the application at runtime.
That's a great way to explain the confusing Mach-O file application. Makes sense for the kernel to know the difference, but for applications it would only matter if "optional libs" had the potential of using too much RAM during runtime.... does that ever happen?
Anyway, .dylib is the "correct" extension on the Mac and also the extension
that the Rubber Band build system uses as of right now, and changing it could break unknown other build systems. So there would have to be a very good reason!
Good, good, I thought the issue was related to multi arch mason builds within rubberband. But it looks like other packages are managing the situation in different ways within pkgsrc. If you don't mind, I'd like to keep this issue open, it looks like rubberband is at 1.9.2, so there may be some other build/dep issues, as I try and bump the version, too.
-George
-- George Georgalis, (415) 894-2710, http://www.galis.org/
@cannam it looks like you fixed it ;-) I bumped pkgsrc rb from 1.8.1 to 3.1.2 removed a meson patch related to ninja (that seems to have been addressed) and pkgsrc builds on NetBSD and MacOS without any lib renaming needed. Not sure why the right thing happens with .so entries in the manifest (PLIST) becoming .dylib files, but all is good. :-)
Hi, pkgsrc is a multi arch/os package binary, and src build infrastructure. It has the distinct advantage of enabling identical build infra for an identical software/version suite of packages, so you get the same software/deps environment on Linux/Mac/BSD, for example.
Presently there is an issue because ld makes dynlib files on mac and so files on other os, this is confusing to the installer because "rubberband" requires a different manifest on different os... https://gnats.netbsd.org/cgi-bin/query-pr-single.pl?number=57262
This is not a fault of rubberband, but perhaps it would be possible to configure rubberband to output .so files on mac, without consequence? Perhaps pkgsrc will do that on mac after build? Or, do you have a suggestion?