CI: add Xcode 15.1 #384

mgeier · 2023-12-21T20:36:32Z

This is stacked on top of #383.

HaHeho · 2023-12-21T21:54:15Z

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 · 2023-12-22T22:38:23Z

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 · 2023-12-23T00:56:52Z

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 · 2023-12-23T10:05:29Z

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 · 2023-12-23T17:06:56Z

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 · 2023-12-30T00:34:22Z

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 · 2024-01-02T16:20:43Z

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 · 2024-01-02T17:28:46Z

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 · 2024-01-03T18:05:18Z

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.

mgeier · 2024-10-01T18:39:42Z

How should we proceed with this?

I suggest simply disabling the Intersense tracker in CI for macOS.

@HaHeho Do you still have problems with libmysofa?

JensAhrens · 2024-10-02T07:04:49Z

I agree with disabling the Intersense tracker. I have never seen any audio person using other than ourselves. And the last time that we used it was probably around the year 2011.

HaHeho · 2024-10-02T18:41:02Z

How should we proceed with this?

I suggest simply disabling the InterSense tracker in CI for macOS.

Yes, that is a good compromise. Merging this is fine ...

@HaHeho Do you still have problems with libmysofa?

... however, the problem of specific libraries (like libintersense) not being linked correctly remains. This seems to affect only the combination of macos-13 with Xcode_15. The linking issue does not show during compilation but only during execution (see this thread for an exploration and possible circumvention of the problem). It feels like there should be a proper way to fix this with the changed linking behavior of Xcode_15, but we have not found it yet.

Removing the Intersense integration for macos-13, Xcode_15.1 fixes the issue for the CI and users that build locally with the dependencies from the existing homebrew packages. I initially noticed the issue when trying to link the SSR against a self-built version of libmysofa (yielding the identical issue as with libintersense above).

I suspect the issue may arise if any dependencies are built locally with Xcode_15 on macos-13. New releases of homebrew dependencies should hopefully not cause problems as they are (likely) built by CI and not this combination. Either way, the problem seems isolated to Xcode_15 on macos-13, and we have eliminated the CI failure. DIY builders want to return to and continue this thread for a proper fix.

mgeier force-pushed the ci-xcode-15 branch 2 times, most recently from 2bf78d5 to 0dd3cce Compare December 22, 2023 16:48

mgeier mentioned this pull request Mar 24, 2024

CI: add macos-14 #394

Merged

mgeier added 2 commits October 1, 2024 20:11

CI: add Xcode 15.1

9c726ea

CI: don't test Intersense SDK on macOS

44761fb

mgeier force-pushed the ci-xcode-15 branch from a29acd6 to 44761fb Compare October 1, 2024 18:16

mgeier merged commit f15aeb9 into SoundScapeRenderer:master Oct 2, 2024
12 checks passed

mgeier deleted the ci-xcode-15 branch October 2, 2024 21:05

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

CI: add Xcode 15.1 #384

CI: add Xcode 15.1 #384

mgeier commented Dec 21, 2023

HaHeho commented Dec 21, 2023

mgeier commented Dec 22, 2023

HaHeho commented Dec 23, 2023

mgeier commented Dec 23, 2023

HaHeho commented Dec 23, 2023

HaHeho commented Dec 30, 2023

HaHeho commented Jan 2, 2024

HaHeho commented Jan 2, 2024 •

edited

Loading

HaHeho commented Jan 3, 2024

mgeier commented Oct 1, 2024

JensAhrens commented Oct 2, 2024

HaHeho commented Oct 2, 2024

CI: add Xcode 15.1 #384

CI: add Xcode 15.1 #384

Conversation

mgeier commented Dec 21, 2023

HaHeho commented Dec 21, 2023

mgeier commented Dec 22, 2023

HaHeho commented Dec 23, 2023

mgeier commented Dec 23, 2023

HaHeho commented Dec 23, 2023

HaHeho commented Dec 30, 2023

HaHeho commented Jan 2, 2024

HaHeho commented Jan 2, 2024 • edited Loading

HaHeho commented Jan 3, 2024

mgeier commented Oct 1, 2024

JensAhrens commented Oct 2, 2024

HaHeho commented Oct 2, 2024

HaHeho commented Jan 2, 2024 •

edited

Loading