CI: add Xcode 15.1

[mgeier]

This is stacked on top of #383.

[HaHeho]

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

[mgeier]

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.

[HaHeho]

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?

[mgeier]

Does that mean my version is incorrectly built or installed, although it is discovered during ./configure and make?

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 on macos-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

[HaHeho]

Does that mean my version is incorrectly built or installed, although it is discovered during ./configure and make?

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.

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

[HaHeho]

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?

[HaHeho]

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?

[HaHeho]

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?

[HaHeho]

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.