search

breakfastquay / rubberband

Official mirror of Rubber Band Library, an audio time-stretching and pitch-shifting library.
http://breakfastquay.com/rubberband/
GNU General Public License v2.0
561 stars 89 forks source link

dynlib vs so files #79

Closed georgalis closed 1 year ago

georgalis commented 1 year ago

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?

cannam commented 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!

georgalis commented 1 year ago

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...

find /opt/pkg-2022Q4/lib -name *so -type f | wc -l

 137

find /opt/pkg-2022Q4/lib -name *dylib -type f | wc -l

 282

find /opt/pkg-2022Q4/lib -name *so -type l -exec ls -l {} \;

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/

georgalis commented 1 year ago

@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. :-)