Link with libjack.0.dylib instead of libjack.0.1.0.dylib on macOS

dyfer commented 3 years ago

Summary

I wonder if software linking against jack2 on macOS could link against libjack.0.dylib, instead of libjack.0.1.0.dylib. Some older Jack versions only provide the former, but not the latter.

Basic example

As an example, I've build JackTrip program, switching between Jack2 versions. JackTrip built with Jack2 1.9.17 reports:

$ otool -L jacktrip
jacktrip:
    /usr/local/lib/libjack.0.1.0.dylib (compatibility version 0.1.0, current version 1.9.17)

JackTrip built with Jack2 1.9.16 reports:

$ otool -L jacktrip
jacktrip:
    /usr/local/lib/libjack.0.dylib (compatibility version 0.0.0, current version 0.1.0)

Motivation

On macOS, software linked against Jack2 1.9.17 links against the libjack.0.1.0.dylib library, while software linked against Jack2 1.9.16 links against the libjack.0.dylib. The libjack.0.1.0.dylib file was not provided by some earlier Jack versions so software linked against the current Jack2 does not work with some older Jack installations, despite being API-compatible.

I think this change has been introduced while workin on https://github.com/jackaudio/jack2/issues/640. Changes introduced there were helpful for compatibility "the other way around" - for software built using earlier versions of Jack to run with the current Jack2. These changes were mostly about the reported library version, AFAIU.

Why are we doing this? What use cases does it support? What is the expected outcome?

On macOS using libjack.0.dylib for linking would allow software build on systems with Jack2 1.9.17 and later to also run on systems with Jack 1.9.11 (i.e. Jack from the JackOSX package). Jack 1.9.11 does not provide libjack.0.1.0.dylib, but it does provide libjack.0.dylib. This request only pertains to the library name. The API compatibility is already maintained.

falkTX commented 3 years ago

I think at this point we really should stop using the old jackosx 1.9.11 binaries. They are 100% unsupported, the previous jack2 author can't even build them anymore so it is pointless to give it attention. Let's please focus on the new stuff.

That said, if you find a way to make this work without affecting new programs, I am all ears. PRs welcome and all that.

dyfer commented 3 years ago

Thanks for the response. I started looking into that and I don't understand what's the desirable naming for the linked libraries. Currently in 1.9.17 we have:

$ otool -L /usr/local/lib/libjack.dylib      
/usr/local/lib/libjack.dylib:
    /usr/local/lib/libjack.0.1.0.dylib (compatibility version 0.1.0, current version 1.9.17)

$ otool -L /usr/local/lib/libjack.0.dylib
/usr/local/lib/libjack.0.dylib:
    /usr/local/lib/libjack.0.1.0.dylib (compatibility version 0.1.0, current version 1.9.17)

$ otool -L /usr/local/lib/libjack.0.1.0.dylib
/usr/local/lib/libjack.0.1.0.dylib:
    /usr/local/lib/libjack.0.1.0.dylib (compatibility version 0.1.0, current version 1.9.17)

and libjack.0.1.0.dylib is a symlink to libjack.0.dylib:

$ ls -l /usr/local/lib/libjack.0.1.0.dylib
lrwxr-xr-x  1 root  wheel  15 Mar 23 11:12 /usr/local/lib/libjack.0.1.0.dylib -> libjack.0.dylib

Is this correct? Should they all be linked to libjack.0.1.0.dylib? Could that be libjack.0.dylib instead? I see a note about it here, but I don't fully understand whether the full vnum or the shorter one (cnum?) should be the primary library.

falkTX commented 3 years ago

without thinking too much, I can say libjack.0.dylib is the wanted target library to link against.

but now going deeper... on linux we have similar situation. let's take fftw as example.

ls -al /usr/lib/x86_64-linux-gnu/libfftw3.*so*
lrwxrwxrwx 1 root root      17 Nov 30  2019 /usr/lib/x86_64-linux-gnu/libfftw3.so -> libfftw3.so.3.5.8
lrwxrwxrwx 1 root root      17 Nov 30  2019 /usr/lib/x86_64-linux-gnu/libfftw3.so.3 -> libfftw3.so.3.5.8
-rw-r--r-- 1 root root 2115912 Nov 30  2019 /usr/lib/x86_64-linux-gnu/libfftw3.so.3.5.8

we do not want to link against libfftw3.so.3.5.8 as that would be bumped on every minor release. linking against libfftw3.so is also undesired, as that would only allow 1 single fftw3 shared lib to exist on the system (instead of say, libfftw3.so.3 and if ABI/API breaks a libfftw3.so.4 onwards for every breakage)

So, typically libfftw3.so is the target for linking stage (so it picks whatever is the current symlink) but during runtime libfftw3.so.3 is used.

from what I know, JACK2 is following the same. If not, it is a bug.

dyfer commented 3 years ago

without thinking too much, I can say libjack.0.dylib is the wanted target library to link against.

from what I know, JACK2 is following the same. If not, it is a bug.

From my first comment:

$ otool -L jacktrip
jacktrip:
  /usr/local/lib/libjack.0.1.0.dylib (compatibility version 0.1.0, current version 1.9.17)

AFAICT currently libjack.0.1.0.dylib is used as the target library, not libjack.0.dylib. Is this a bug then?

falkTX commented 3 years ago

From what I see in your first post, yes, it seems like a real bug.

jackaudio / jack2