Move to GitHub worflow runner macos-12

[daschuer]

This fixes: #13248
Deadline is 2024-06-28

[daschuer]

The test fails rather strange.

360/812 Test #360: GlobalTrackCacheTest.concurrentDelete ......................................................***Timeout  45.02 sec
dlopen error : dlopen(libjack.0.dylib, 0x0001): tried: 'libjack.0.dylib' (no such file), '/usr/local/lib/libjack.0.dylib' (no such file), '/usr/lib/libjack.0.dylib' (no such file), '/Users/runner/work/mixxx/mixxx/libjack.0.dylib' (no such file) 
dlopen error : dlopen(/usr/local/lib/libjack.0.dylib, 0x0001): tried: '/usr/local/lib/libjack.0.dylib' (no such file) 
Note: Google Test filter = GlobalTrackCacheTest.concurrentDelete
[==========] Running 1 test from 1 test suite.
[----------] Global test environment set-up.
[----------] 1 test from GlobalTrackCacheTest
[ RUN      ] GlobalTrackCacheTest.concurrentDelete
info [0x6000037f02b0] GlobalTrackCache - Creating instance

For my understanding libjack is linked statically, so there should be no reason for loading the dylib at runtime. It is also interesting why the arm build is not failing.

[daschuer]

jackaudio/jack2#862 might be related.
@fwcd Do you have an idea?

[fwcd]

The linked issue looks unrelated, library validation is different from not finding the library. That shouldn't be needed in the first place though, since we're almost exclusively using static libraries from vcpkg, right?

You could check the configure logs, perhaps CMake decided to pick a system library over vcpkg for JACK, in that case I would have expected link errors at an earlier stage though.

[Swiftb0y]

Yes, I'm pretty sure the dlopen issue is completely unrelated, I've seen that numerous times on other macOS CI failures which had nothing to do with jack. I'm pretty sure the concurrentDelete test has some threading-related issues which surface now.

[fwcd]

I remember seeing library loading errors with JACK when launching Mixxx normally on macOS too, even though we don't even use JACK on macOS. So probably something to figure out.

But yeah, the test failure is probably completely unrelated.

[JoergAtGithub]

You could check the configure logs, perhaps CMake decided to pick a system library over vcpkg for JACK, in that case I would have expected link errors at an earlier stage though.

Our vcpkg.json doesn't contain jack2

[daschuer]

The `dlopen error : dlopen(libjack.0.dylib, 0x0001):``is originated from here:
https://github.com/jackaudio/jack2/blob/c46c1b16e0eabbcf55ef69b0ffb96dfe16521cfa/common/JackWeakAPI.c#L55

[daschuer]

We do build jack2 with vcpkg. Int comes in as dependency. I am currently struggling to find out how, because Portaudio does not have this dependency.

2024-05-27T05:28:03.9724760Z -- Found JACK: /Users/runner/buildenv/mixxx-deps-2.4-x64-osx-min1012-release-07b9859/installed/x64-osx-min1012-release/lib/libjack.a (found version "1.9") 

[Swiftb0y]

Let me emphasize again that the jack dlopen error has nothing to do with the failing test!

[daschuer]

Let me emphasize again that the jack dlopen error has nothing to do with the failing test!

Confirmed. That is not even an error. Portaudio Probes the JACK API like all others. Unfortunately Jack has decided to print this error unconditionally. I think I will file a bug against Jack.

[daschuer]

This is the upstream report: jackaudio/jack2#977

[daschuer]

This is now working but required a good amount of testing. 24 Days left.

[Swiftb0y]

LGTM. Thank you for the testing.