jellyfin / jellyfin-media-player

Jellyfin Desktop Client
GNU General Public License v2.0
3.11k stars 312 forks source link

[macOS] v1.10.0 arm64 build crashed when launching on macOS Ventura #627

Open shine5402 opened 4 months ago

shine5402 commented 4 months ago

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)

Date/Time:             2024-05-15 17:29:10.4269 +0800
OS Version:            macOS 13.6.6 (22G630)
Report Version:        12

System Integrity Protection: enabled

Crashed Thread:        0

Exception Type:        EXC_CRASH (SIGABRT)
Exception Codes:       0x0000000000000000, 0x0000000000000000

Termination Reason:    Namespace DYLD, Code 4 Symbol missing
Symbol not found: _$sSo13NSWindowLevela6AppKit01_cdD23NumericRawRepresentableACMc
Referenced from: <2E98933C-5ADA-3FCB-97DE-95A140BA166D> /Volumes/VOLUME/Jellyfin Media Player.app/Contents/Frameworks/libmpv.2.dylib (built for macOS 14.0 which is newer than running OS)
Expected in:     <5F91782E-BD13-3897-900C-EA11E6AFFE14> /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit
(terminated at launch; ignore backtrace)

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

shine5402 commented 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.

gnattu commented 4 months ago

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.

kambala-decapitator commented 4 months ago

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.

shine5402 commented 4 months ago

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.

gnattu commented 4 months ago

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.

kambala-decapitator commented 4 months ago

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

iwalton3 commented 4 months ago

Please test the dev build: https://github.com/jellyfin/jellyfin-media-player/actions/runs/9103571912

gnattu commented 4 months ago

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.

shine5402 commented 4 months ago

I've test it and yep, arm64 builds still crashes by the exact same issue. Intel builds works fine now, as expected by #628