Homebrew replaced its `sdl2` formula with `sdl2-compat`, a compatibility
layer that provides the SDL2 API by `dlopen`-ing the real SDL3 library
at runtime. The macOS CI build (`build-macos.yml`) pulls this via `brew
install mpv`, so the app now links `libSDL2-2.0.0.dylib` which is
actually `sdl2-compat`, and every nightly ships it in
`Contents/Frameworks`.
SDL3 is not a linker dependency, so it never shows up in `otool -L`
output and the `CompleteBundleMac` fixup loop never copies it into the
app bundle. At runtime `sdl2-compat` looks for `libSDL3.dylib` relative
to its own loader path, cannot find it, prints "Failed loading SDL3
library." and aborts during dyld initialization, since the library is
missing. This regression appeared once Homebrew's SDL2 became the
`sdl2-compat` shim, so older nightly builds (built against genuine SDL2)
are unaffected.
This detects `sdl2-compat` inside the bundle (it is the only
`libSDL2-2.0.0.dylib` containing the `libSDL3.dylib` loader string) and
explicitly copies libSDL3 from the Homebrew prefix into
`Contents/Frameworks/libSDL3.dylib`, using the same `install-id`
convention as the other bundled dylibs so `codesign` and the existing
fixup steps keep working. If SDL3 cannot be found at install time a
warning is printed instead of failing silently.
Fixes#1225
Detect portable marker file (portable or portable.txt) next to exe
and store data/cache in app directory instead of AppData.
ZIP package includes marker file for out-of-box portable use.
- Support user-level install (no admin required)
- Bundle MSVC runtime DLLs from deps/vcruntime
- Offer system-wide VCRedist install when running as admin
- Add portable ZIP artifact (windows_zip target)
- Add combined windows_all target for installer + ZIP
It is really late so I'm calling it here. I wanted to put this out for relevant people to get eyes on, in order to aid in getting the Windows build of v2.0.0 out. Apologies in advance for not following any contrib guidelines or there being messes. I'm leaving in the build scripts I used for now. The build scripts still contain a few hardcoded visual studio related values for now. At the moment when I run the app on a different machine to the dev VM I'm using the qt web view doesn't seem to be rendering.
summary of where this is at:
the whole thing builds
works on my Windows 11 virtual machine
short summary of what I did:
A couple of qt6 updates specific to windows were addressed.
Some build system issues were addressed
did some minor refactoring to sieve out binary build dependencies from generated build files since its a lot easier when you can just delete the build folder to run a clean build
- Fixes build and package for at least Ubuntu 24.04
- Defaulted to building and statically linking mpvqt as most platforms
lack packages for it.
- Workaround mpvqt requiring qt>=6.5 for wayland support with a few
workarounds when statically building.
- Additionally, default to xcb on qt<6.5 due to mpvqt using qt>=6.5
fetures for wayland. Wayland can be forced, but seems to give black
video.
- Remove --disable-web-security flag as it's no longer needed
- There are no CORS nor CPS issues
- mpv integration works
- the service worker works
- Bundle JMP web bridge resources in application binary (file:// -> qrc://)
- This keeps installs cleaner and removes the risk of the native
files going missing or using the incorrect paths.
- Using file:// also had some issues with CSP
- The JS assets are combined into a single JS script which is
injected as a user script. This bypasses CSP issues.
- Replace connectivity check and web HTML retrieval JavaScript methods
with C++ methods. This works around CORS issues on the server
selection page.
This commit also consolidates the default configuration directories
and makes the cache path consistent.
From:
~/.cache/Jellyfin Media Player
~/.local/share/jellyfinmediaplayer
~/.local/share/Jellyfin Media Player
To just:
~/.cache/jellyfinmediaplayer
~/.local/share/jellyfinmediaplayer
CMP0026 OLD behavior was removed in cmake 4.0. This should be safe as,
at least on Linux, there doesn't seem to be any resources being copied.
There might still be changes needed to fix compatibility with cmake 4.0
when building for macos.
Anderson Mesquita