Open dyfer opened 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.
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.
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.
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?
From what I see in your first post, yes, it seems like a real bug.
Summary
I wonder if software linking against jack2 on macOS could link against
libjack.0.dylib
, instead oflibjack.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:
JackTrip built with Jack2 1.9.16 reports:
Motivation
On macOS, software linked against Jack2
1.9.17
links against thelibjack.0.1.0.dylib
library, while software linked against Jack21.9.16
links against thelibjack.0.dylib
. Thelibjack.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.
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 providelibjack.0.1.0.dylib
, but it does providelibjack.0.dylib
. This request only pertains to the library name. The API compatibility is already maintained.