Open shine5402 opened 4 months ago
I just realized that libmpv bundled with mac builds is come from brew
after reading README more carefully(sorry!). It seems like that brew
would always getting bottles optimized for the OS version that brew is running on. From #571, arm64 build is built on macOS 14 runner. That would explain it.
It is inevitable if we still want to use GitHub Runners to produce arm64 builds, because only sonoma+ runners have Apple Silicon environment, and everything older is Intel only.
It is inevitable if we still want to use GitHub Runners to produce arm64 builds, because only sonoma+ runners have Apple Silicon environment, and everything older is Intel only.
this means it's time to stop using deps from brew and build them manually where you can control the deployment target. You can still build them using GhA of course.
I would like to vote for building these library from scratch with deployment target changed but yes it would bring up much more hassle to deal with. It really depends on deciding if older(though still supported by Apple) macOS versions should be supported by arm64 builds. Previous x86_64 builds are running pretty great on my mac so I will not complain about lacking of arm64 builds for Ventura if fixing this issue is not that prioritized. The release note should be updated to mention it though.
Anyway, by reading build script from brew(https://github.com/Homebrew/homebrew-core/blob/master/Formula/m/mpv.rb), it seems like that building mpv from scratch on mac is pretty clean. They are using meson
and meson
should have aware of MACOSX_DEPLOYMENT_TARGET(https://mesonbuild.com/meson-python/reference/environment-variables.html#envvar-MACOSX_DEPLOYMENT_TARGET). I'm not familiar with meson nor mpv so it's pretty much guessing backed by some casual google search though.
It is inevitable if we still want to use GitHub Runners to produce arm64 builds, because only sonoma+ runners have Apple Silicon environment, and everything older is Intel only.
this means it's time to stop using deps from brew and build them manually where you can control the deployment target. You can still build them using GhA of course.
PRs are always welcomed.
if someone is willing to try that, I'd suggest to use Conan (had had bad results with vcpkg back when I was choosing package manager for the first time and never tried it since then).
Please test the dev build: https://github.com/jellyfin/jellyfin-media-player/actions/runs/9103571912
Please test the dev build: https://github.com/jellyfin/jellyfin-media-player/actions/runs/9103571912
No this won't make it run on ventura. It is still Sonoma+ only for Apple silicon. The dev build only fixes the Intel builds with wrong search path, and does not change Apple Silicon dependency of the macOS version.
I've test it and yep, arm64 builds still crashes by the exact same issue. Intel builds works fine now, as expected by #628
Describe the bug Jellyfin Media Player v1.10.0 arm64 build will crash when running on macOS Ventura(or anything that is not Sonoma) due to failed dyld resolve caused by bundled libmpv.2.dylib , which requiring macOS 14.0 to run.
To Reproduce Just launch it on a arm64 mac running macOS Ventura.
Expected behavior It should launch fine.
Screenshots (None. Error message from macOS's Console will be pasted below.)
Desktop (please complete the following information):
Additional context
Messages from system crash reporter(Console)
I suppose it is caused by not setting proper macOS deployment target when building given library, which would fallback to current OS version, at least on arm64 macs that I touched. So compiler will drop all dynamic backward compatibility measure for anything before macOS 14.0, leading to a non-existing symbol expected in AppKit comes with OS. CMake provides MACOSX_DEPLOYMENT_TARGET variable and qmake provides QMAKE_MACOSX_DEPLOYMENT_TARGET to alter this value, and they will pass this to clang/gcc via
-mmacos-version-min=<arg>
.