Open mgeier opened 8 months ago
macos-13, Xcode_15.1
failed, although the reason is not apparent from the build log.
It may be the same issue I was facing when building locally with Apple clang version 15.0.0 (clang-1500.1.0.2.5)
. The binaries build successfully, but the manual compilation fails since the binaries don't run since libmysofa.dylib
is not found.
❯ src/ssr-binaural --version
dyld[56379]: Library not loaded: libmysofa.1.dylib
Referenced from: <2F38516E-CBBC-3FF0-9CEB-7C4FC00A912C> /Users/helmholz/Desktop/ssr/src/ssr-binaural
Reason: tried: 'libmysofa.1.dylib' (no such file), '/System/Volumes/Preboot/Cryptexes/OSlibmysofa.1.dylib' (no such file), 'libmysofa.1.dylib' (no such file), '/Users/helmholz/Desktop/ssr/libmysofa.1.dylib' (no such file), '/System/Volumes/Preboot/Cryptexes/OS/Users/helmholz/Desktop/ssr/libmysofa.1.dylib' (no such file), '/Users/helmholz/Desktop/ssr/libmysofa.1.dylib' (no such file)
This is after I compiled when excluding the InterSense trackers. For that library, the same thing happens.
Curiously, this works, and the library is found, in my case, cd src && ssr-binaural --version
. There must be an issue with the linking as confirmed by (remember this is without InterSense):
❯ otool -L src/ssr-binaural
src/ssr-binaural:
libmysofa.1.dylib (compatibility version 1.0.0, current version 1.3.22)
/usr/local/opt/libsndfile/lib/libsndfile.1.dylib (compatibility version 2.0.0, current version 2.37.0)
/usr/local/opt/fftw/lib/libfftw3f.3.dylib (compatibility version 10.0.0, current version 10.10.0)
/usr/local/opt/jack/lib/libjack.0.1.0.dylib (compatibility version 0.1.0, current version 1.9.22)
/usr/lib/libxml2.2.dylib (compatibility version 10.0.0, current version 10.9.0)
/System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL (compatibility version 1.0.0, current version 1.0.0)
/usr/local/opt/qt@5/lib/QtOpenGL.framework/Versions/5/QtOpenGL (compatibility version 5.15.0, current version 5.15.11)
/usr/local/opt/qt@5/lib/QtWidgets.framework/Versions/5/QtWidgets (compatibility version 5.15.0, current version 5.15.11)
/usr/local/opt/qt@5/lib/QtGui.framework/Versions/5/QtGui (compatibility version 5.15.0, current version 5.15.11)
/usr/local/opt/qt@5/lib/QtCore.framework/Versions/5/QtCore (compatibility version 5.15.0, current version 5.15.11)
/usr/local/opt/fmt/lib/libfmt.10.dylib (compatibility version 10.0.0, current version 10.1.0)
/usr/local/lib/libasdf.1.dylib (compatibility version 1.0.0, current version 1.0.0)
/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 1600.157.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1336.61.1)
I have yet to find out how to fix this during compilation. Afterward, it can be fixed by install_name_tool -change libmysofa.1.dylib /usr/local/lib/libmysofa.dylib src/ssr-binaural
, but this would have to be done for each binary separately and obviously should not be necessary.
Apologies if this is not the issue with macos-13, Xcode_15.1
here. Regardless, I would appreciate a hint on how to fix this problem during compilation. :)
Apologies if this is not the issue with
macos-13, Xcode_15.1
here.
It looks like it's indeed the same problem.
I have added some debugging output and I'm getting very similar messages in https://github.com/SoundScapeRenderer/ssr/actions/runs/7302083802/job/19900033809:
$ src/ssr-binaural --version
dyld[21992]: Library not loaded: libisense.dylib
Referenced from: <CE98310C-3227-3791-A026-EC8826506FFF> /Users/runner/work/ssr/ssr/src/ssr-binaural
Reason: tried: 'libisense.dylib' (no such file), '/System/Volumes/Preboot/Cryptexes/OSlibisense.dylib' (no such file), 'libisense.dylib' (no such file), '/Users/runner/work/ssr/ssr/libisense.dylib' (no such file), '/System/Volumes/Preboot/Cryptexes/OS/Users/runner/work/ssr/ssr/libisense.dylib' (no such file), '/Users/runner/work/ssr/ssr/libisense.dylib' (no such file)
Contrary to your report, it also doesn't work here:
$ cd src && ./ssr-binaural --version
dyld[21997]: Library not loaded: libisense.dylib
Referenced from: <CE98310C-3227-3791-A026-EC8826506FFF> /Users/runner/work/ssr/ssr/src/ssr-binaural
Reason: tried: 'libisense.dylib' (no such file), '/System/Volumes/Preboot/Cryptexes/OSlibisense.dylib' (no such file), 'libisense.dylib' (no such file), '/Users/runner/work/ssr/ssr/src/libisense.dylib' (no such file), '/System/Volumes/Preboot/Cryptexes/OS/Users/runner/work/ssr/ssr/src/libisense.dylib' (no such file), '/Users/runner/work/ssr/ssr/src/libisense.dylib' (no such file)
This is the result of otool -L
:
$ otool -L src/ssr-binaural
src/ssr-binaural:
libisense.dylib (compatibility version 0.0.0, current version 0.0.0)
/usr/local/opt/libmysofa/lib/libmysofa.1.dylib (compatibility version 1.0.0, current version 1.3.2)
/usr/local/opt/libsndfile/lib/libsndfile.1.dylib (compatibility version 2.0.0, current version 2.37.0)
/usr/local/opt/fftw/lib/libfftw3f.3.dylib (compatibility version 10.0.0, current version 10.10.0)
/usr/local/opt/jack/lib/libjack.0.1.0.dylib (compatibility version 0.1.0, current version 1.9.22)
/usr/lib/libxml2.2.dylib (compatibility version 10.0.0, current version 10.9.0)
/System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL (compatibility version 1.0.0, current version 1.0.0)
/usr/local/opt/qt@5/lib/QtOpenGL.framework/Versions/5/QtOpenGL (compatibility version 5.15.0, current version 5.15.11)
/usr/local/opt/qt@5/lib/QtWidgets.framework/Versions/5/QtWidgets (compatibility version 5.15.0, current version 5.15.11)
/usr/local/opt/qt@5/lib/QtGui.framework/Versions/5/QtGui (compatibility version 5.15.0, current version 5.15.11)
/usr/local/opt/qt@5/lib/QtCore.framework/Versions/5/QtCore (compatibility version 5.15.0, current version 5.15.11)
/usr/local/opt/fmt/lib/libfmt.10.dylib (compatibility version 10.0.0, current version 10.1.0)
/usr/local/lib/libasdf.1.dylib (compatibility version 1.0.0, current version 1.0.0)
/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 1600.157.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1336.61.1)
I find it interesting that you said you get the error with libisense.dylib
, but when you disable it, you get the identical error with libmysofa.1.dylib
.
It looks like the error isn't related to the library itself, but just to the first library that happens to be in the list.
It looks like the error isn't related to the library itself but just to the first library that happens to be in the list.
No, not in my case. When I include libisense.dylib
again, both are incorrect and cannot be loaded.
❯ otool -L src/ssr-binaural
src/ssr-binaural:
libisense.dylib (compatibility version 0.0.0, current version 0.0.0)
libmysofa.1.dylib (compatibility version 1.0.0, current version 1.3.22)
/usr/local/opt/libsndfile/lib/libsndfile.1.dylib (compatibility version 2.0.0, current version 2.37.0)
/usr/local/opt/fftw/lib/libfftw3f.3.dylib (compatibility version 10.0.0, current version 10.10.0)
/usr/local/opt/jack/lib/libjack.0.1.0.dylib (compatibility version 0.1.0, current version 1.9.22)
/usr/lib/libxml2.2.dylib (compatibility version 10.0.0, current version 10.9.0)
/System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL (compatibility version 1.0.0, current version 1.0.0)
/usr/local/opt/qt@5/lib/QtOpenGL.framework/Versions/5/QtOpenGL (compatibility version 5.15.0, current version 5.15.11)
/usr/local/opt/qt@5/lib/QtWidgets.framework/Versions/5/QtWidgets (compatibility version 5.15.0, current version 5.15.11)
/usr/local/opt/qt@5/lib/QtGui.framework/Versions/5/QtGui (compatibility version 5.15.0, current version 5.15.11)
/usr/local/opt/qt@5/lib/QtCore.framework/Versions/5/QtCore (compatibility version 5.15.0, current version 5.15.11)
/usr/local/opt/fmt/lib/libfmt.10.dylib (compatibility version 10.0.0, current version 10.1.0)
/usr/local/opt/asdf/lib/libasdf.1.dylib (compatibility version 1.0.0, current version 1.0.0)
/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 1600.157.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1336.61.1)
libmysofa.1.dylib
works in CI, using the v1.3.2
homebrew version. I am instead trying to use a self-built and modified version located at /usr/local/lib/libmysofa.1.dylib -> libmysofa.1.3.22.dylib
. When I link the homebrew version and rebuild, libmysofa.1.dylib
is found (same otool
output as in CI). Does that mean my version is incorrectly built or installed, although it is discovered during ./configure
and make
?
Anyhow, libisense.dylib
seems to struggle with the same issue now on macos-13, Xcode_15.1
?
Does that mean my version is incorrectly built or installed, although it is discovered during
./configure
andmake
?
I don't know.
I would expect that when make
runs successfully, ssr-binaural
should also run at least on the same machine, but apparently it doesn't ...
You can try experimenting with LD_LIBRARY_PATH
, DYLD_LIBRARY_PATH
or DYLD_FALLBACK_LIBRARY_PATH
, but I don't really know how those are supposed to be used.
Anyhow,
libisense.dylib
seems to struggle with the same issue now onmacos-13, Xcode_15.1
?
Yeah. But the file is really old and there don't seem to be any more recent releases: https://www.intersense.com/dev-tools
Maybe it simply doesn't work with newer versions, maybe we should disable it in CI?
I have tried it without libisense
, and it works fine: https://github.com/SoundScapeRenderer/ssr/actions/runs/7307021701/job/19912300580
Does that mean my version is incorrectly built or installed, although it is discovered during
./configure
andmake
?I don't know. I would expect that when
make
runs successfully,ssr-binaural
should also run at least on the same machine, but apparently it doesn't ...You can try experimenting with
LD_LIBRARY_PATH
,DYLD_LIBRARY_PATH
orDYLD_FALLBACK_LIBRARY_PATH
, but I don't really know how those are supposed to be used.
Yeah, I've seen those optional paths mentioned before. I have yet to try to fix it this way since setting paths would require an additional step after building. Ideally, we can find a solution by modifying the build process. I will keep investigating how to mitigate the issue. Hopefully, that will work for libmysofa
and libisense
.
Anyhow,
libisense.dylib
seems to struggle with the same issue now onmacos-13, Xcode_15.1
?Yeah. But the file is really old and there don't seem to be any more recent releases: https://www.intersense.com/dev-tools
Maybe it simply doesn't work with newer versions, maybe we should disable it in CI?
I have tried it without
libisense
, and it works fine: https://github.com/SoundScapeRenderer/ssr/actions/runs/7307021701/job/19912300580
I assume most people would be fine without the InterSense integration. However, it seems like a fix for the loading issue cannot be far since executing the binary from its parent directory does not cause the error and since it can be "easily" fixed with install_name_tool -change ...
. Therefore, I don't think this is a problem by the old library, but rather a general change to behavior in either macos-13
or Xcode_15
, which we should understand to prevent further issues with other libraries in the future (like my self-built version of libmysofa
). I will try to find hints about what causes this and how to fix it.
I diffed the CI ./configure
logs from when libisense
was still enabled. The only noteworthy difference is the following.
macos-13, Xcode_14.3
(builds and executed successfully):
checking for -single_module linker flag... yes
macos-13, Xcode_15.1
(builds successfully, but the execution fails):
checking for -single_module linker flag... ld: warning: -single_module is obsolete no
This probably hints at the issue we encounter later when not loading the library correctly?
The loader seems to find the libraries if setting export DYLD_LIBRARY_PATH="/usr/local/lib"
. However, unfortunately, the application segfaults eventually during load, without indicating where or why it happens.
❯ src/ssr-binaural -v
Warning: src/ssr-binaural was compiled for debugging! (configuration.cpp:134)
Trying to set priority...worker thread: policy=SCHED_FIFO, priority=5
Trying to set priority...worker thread: policy=SCHED_FIFO, priority=5
Trying to set priority...worker thread: policy=SCHED_FIFO, priority=5
___
/ ___
___/ / ___
___/ / SSR (SoundScape Renderer) 0.6.1-13-g1de91a4
/ renderer type: BinauralRenderer
Website: <http://spatialaudio.net/ssr/>
Contact: <ssr@spatialaudio.net>
Copyright © 2016 Division of Applied Acoustics, Chalmers University of Technology
Copyright © 2014 Institut für Nachrichtentechnik, Universität Rostock
Copyright © 2012 Quality & Usability Lab, Telekom Innovation Laboratories, TU Berlin
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
apf::JackClient: Connection: BinauralRenderer:out_1 -> system:playback_1
apf::JackClient: Connection returned: -1
apf::JackClient: Unable to connect BinauralRenderer:out_1 -> system:playback_1! Adding this to pending connections ...
apf::JackClient: Connection: BinauralRenderer:out_2 -> system:playback_2
apf::JackClient: Connection returned: -1
apf::JackClient: Unable to connect BinauralRenderer:out_2 -> system:playback_2! Adding this to pending connections ...
apf::JackClient: Activating JACK client.
apf::JackClient: Connecting 2 pending connections ...
apf::JackClient: Connection: BinauralRenderer:out_2 -> system:playback_2
apf::JackClient: Connection returned: 0
apf::JackClient: Connection: BinauralRenderer:out_1 -> system:playback_1
apf::JackClient: Connection returned: 0
apf::JackClient: Still pending connections: 0
[1] 15876 segmentation fault src/ssr-binaural -v
Curiously, the segfault does not occur when omitting the GUI with src/ssr-binaural -G
.
To omit the segfault, the former install_name_tool -change ...
can be employed. However, unset DYLD_LIBRARY_PATH
must also be invoked to avoid receiving a segfault.
Do you have any idea why this happens and how to investigate further?
Nevermind, https://stackoverflow.com/questions/3146274/is-it-ok-to-use-dyld-library-path-on-mac-os-x-and-whats-the-dynamic-library-s explained well why DYLD_FALLBACK_LIBRARY_PATH
should be used instead of DYLD_LIBRARY_PATH
in the above "fix".
To summarize, invoking export DYLD_FALLBACK_LIBRARY_PATH="/usr/local/lib"
fixes the loading issues of libisense. dylib
(and of my custom-built libmysofa.1.dylib
). With this, no modifications during linking and compiling or of the built binaries are required while not yielding a segfault during execution. Remember that this is only necessary for macos-13, Xcode_15.1
, i.e., it is introduced by changes in linking behavior with Apple Clang 15.
However, setting DYLD_FALLBACK_LIBRARY_PATH
is a development tool unsuitable for deployment. Hence, we still need a better solution to yield functioning executables when compiled with Apple Clang 15 or newer (already the standard deployed version with Xcode on macOS 13 and newer and will eventually become the default on GitHub CI).
The current solution fixes at least my local build environment. Since I'm still new to the build process, I'd rather wait for input from a more experienced macOS developer to help resolve the issue during build time. Do you have any ideas, anyone?
I'm out of ideas. The changes in linking behavior with Xcode 15.0
are documented as known issues here. Some problems with that are already supposed to be fixed in Xcode 15.0
here (which the CI and I were using all along). The suggested (temporary) workaround is to use the old linker by supplying the -Wl,-ld_classic
or -Wl,-weak_reference_mismatches,weak
linker options.
I tried this before ./autogen.sh
and saw the flags in the ./configure
output. However, the resulting binaries exhibit the identical problem of not finding libisense.dylib
(and my custom-built libmysofa.1.dylib
), which can be "fixed" manually with either DYLD_FALLBACK_LIBRARY_PATH
or install_name_tool
as described above.
I know that the supplied "names" for the libraries are not according to current conventions. However, versions before Xcode 15
could deal with this. Hence, there should be a more convenient solution to have an otherwise identical build pipeline independent of OS and version.
This is stacked on top of #383.