Road to macOS builds

[gnattu]

I succesfully made a statically linked jellyfin-ffmpeg on macOS:

To support building this on our CI, significant changes need to be made to our builder. I will note the observations during my build process here.

First, macOS targets do not use Docker and cross-compiling; they compile for the native target. To accommodate this, we will need:

• two macOS CI runners, supporting both architectures (x86-64 and arm64).
• modify our builder script to have a macOS native path. It can borrow the ffbuild_dockerbuild function as a common dependency build function.

Additionally, macOS needs special handling on dependencies:

• libiconv, libxml2, OpenCL-Headers, and OpenCL-ICD-Loader should not be built and should be skipped on macOS because they are built-in, and the external implementation confuses the linker, making it hard to find the correct version.
• glib2, libpng, libbrotli, and libunibreak need to be built statically on macOS, in addition to our own dependencies. Some of these require additional patches.
  • glib2 has a hard-coded SDK search path under macOS, which points to MacOSX11.sdk, but that version is deprecated by Apple and removed in the latest toolchains. It needs to be changed to MacOSX.sdk to point to the current version.
  • libbrotli does not honor static build settings and needs to patch CMakeList.txt to build static libraries.
• The ioctl.patch of zvbi erroneously undefines ioctl.h under macOS, causing linking errors. That patch should not be applied.
• gmp shipped configure script relies on an ancient version of macOS libtool, which causes linker errors due to name collisions on macOS, we need to perform autoreconf -i -s to regenerate the file as a workaround.
• libvobris has an ancient linker flag -force_cpusubtype_ALL which dated back to PowerPC era (and only make sense on PowerPC Macs) and is no longer available, need to remove it.
• In some build scripts, we append Libs.private: to generated pkg-config files. However, under macOS, the generated .pc file may already have a Libs.private entry, causing pkg-build to error out during ffmpeg configuration.
• srt and x265 will already have their own entry, but we still need to append our own to libchromaprint.pc.

For all build scripts, we have to also take care of the differences between BSD tools and the GNU tools. Common tools like tar and sed will work differently. Specifically for macOS, the GNU binutils does not support macOS target, so ar need to be replaced with libtool on macOS.

[nyanmisaka]

Take your own pace. The full build script is not necessary for the 10.9 release, just the built binaries. AFAIK Anthonylavado is responsible for packaging Jellyfin Server on MacOS. You can talk to him about how to ship our FFmpeg fork.

And here's our latest release schedule.

[AbandonedCart]

The full build script is not necessary for the 10.9 release, just the built binaries.

If I might make a request that you enable Chromaprint if you are going to do that. It may not matter much to the code Jellyfin experience, but it creates an absolute mess trying to reroute the ffmpeg. The packaged version has a meltdown when you try to change it and there is virtually no documentation for the commandline version. I only managed to do it through a string of forum comments and over-engineering what would have been a simple --enable-chromaprint in the original build.

[gnattu]

Current ffmpeg shipped with Jellyfin macOS is not our custom build and Chromaprint will be enabled in our builds in the following 10.9 version.

[AbandonedCart]

If I remember right, your current version is from https://evermeet.cx/ffmpeg/

[gnattu]

Why it requires click? We are not using it anywhere

[gnattu]

I manually check for EVERY binary it generates with otool and it does not link to anything other than the macOS built-ins. Click is not our dependency, and if it appears to yours, can I ask you sharing what otool -L ffmpeg and ffmpeg -version outputs?

[gnattu]

Click is not even installed on my machine:

Are you really using our build of ffmpeg or you are just getting a random build from "somewhere"?

[gnattu]

It does not link to "click" and runs fine without it(mine does not, and it runs).

Which macOS version are you on? And what will it tell you when you removed the "click" from homebrew?

[AbandonedCart]

If nobody else reports it, then call it a fluke. Mine works now and it's really not worth the aggression.

[gnattu]

If nobody else reports it, then call it a fluke.

It is not a "fluke". I test the portability in clean VMs (nothing is installed via Homebrew) and ensure it runs. I have a very high level of confidence that it would work for most of the intended environments. I even tested the binary you pointed to with a new macOS 12 VM, and it runs as expected. If it breaks in a certain environment, then we need to investigate what's unique about that environment because it should work on a brand new Mac.

it's really not worth the aggression.
I can't tell you why it happened, but I don't entirely appreciate the accusation.

If you believe that asking questions implies accusation and aggression, I'd like to clarify why I asked those questions in the first place.

Click is a command-line utility for managing Kubernetes clusters, and it has no connection to our ffmpeg. Therefore, it doesn't make sense for any part of ffmpeg to rely on it. The only logical explanation, in my opinion, would be that the user is using the wrong binary. That's why I asked you to confirm that the binary you tested is the one provided by us.

After confirming that you are indeed using a binary from us, which is good, the unexpected behavior prompted me to ask additional questions about your environment and request the error message when click is not installed. However, you refused to answer questions and dismissed my work as a "fluke" and call my questions "aggression."

If you feel that my questions came across as aggressive accusations, I apologize for any misunderstanding. Perhaps I could have explained my intentions better. However, I also want to express that I didn't appreciate the way you responded to my inquiries.

[nyanmisaka]

To be fair, one should not be too picky about a daily build that is being introduced for the first time and has not yet been released. There may be subsequent fixes and improvements in the Release Candidate phase.

If someone encounters an issue but cannot wait for the developer to fix it immediately, then he should spend his own time looking into it and even open a PR. This is the essence of open source.

[AbandonedCart]

I don't know why it asked for click. Installing click fixed it. It kept working after it was uninstalled. Seems to be the literal definition of a fluke, but you could also call it a coincidence if you like. I marked the comments resolved. Best of luck.

[gnattu]

It kept working after it was uninstalled.

Glad to hear that.

Seems to be the literal definition of a fluke, but you could also call it a coincidence if you like.

Seems to be the case. No idea what is asking for a Kubernetes management tool. It's akin to saying an aircraft requires an anchor to fly. If it's referring to python-click, then it makes more sense, as some Python scripts require it to provide a command-line interface. There could be a chance that a Python script is invoked accidentally but for only once.

[AbandonedCart]

It is python-click that it needed. Installing the wrong one probably fixed a broken link after switching Homebrew Python to official. Seems as good an explanation as any.