Building MKVToolNix with Gui on a mac

Help
1

Can anyone give build instructions to build MKVToolNix with gui on macos? The scripts in packaging seem to be able to build an .app on macos but I don’t get it working and there are no build instructions. It would be really nice if someone could give build instructions so that I can try building it on an arm-mac.

Apple Silicon: retirement of Rosetta 2
2

There’s no documentation apart from the scripts in packaging/macos. Basically:

  • install XCode
  • run XCode’s GUI at least once 'cause you must confirm the EULA or something like that; confirm with clang afterwards that you can run it from the CLI
  • the config for the main build script is packaging/macos/config.sh; you can override any of those settings with a an optional file packaging/macos/config.local.sh which is sourced after config.sh if it exists
  • run packaging/macos/build.sh; this should download all required sources & build the whole thing

The whole build process assumes that you have a developer SSL certificate from Apple for signing the binaries (this is done during the last step, when creating the DMG). That one can only be obtained by joining Apple’s developer program, which costs 99€/year here in Germany. If you’ve done that, you can use XCode to request official certificates. You’ll have to overwrite at least this setting in your config.local.sh as the default in config.sh is my own certificate’s ID, obviously. The certificates are stored in your login key chain.

Sources etc. are downloaded to ~/opt/…; building happens in ~/tmp/…

3

Thank you for the response. I was able to run the script build.sh successfully after creating the ~/opt folder and putting the xsl stylesheets and a source subfolder with the mkvtoolnix-92.0.tar.xz in it. After running the build script I got the mkvtoolnix directory in ~/tmp. Going to this directory and running rake and rake install created an app for me, but it is damaged and can’t be opened even with gatekeeper disabled. If I show the package contents of the app and run mkvtoolnix-gui from the terminal I get an error that an dylib is missing. Inside the app is no folder with dylibs like in your build. Also I’ve got an .app and not an dmg like you have explained. I wonder if this is related to code signing because I’ve used an self signed certificate and I don’t have an apple developer account. Is it possible to disable code signing? You should still be able to open an app without code signing, if gatekeeper is disabled?

4

Only running build.sh without arguments will indeed build MKVToolNix, but not the DMG. Building the DMG is done with an additional call to ./build.sh dmg. The code signing only happens during the DMG build, not earlier.

You can disable code signing by setting the variable SIGNATURE_IDENTITY empty. As said earlier, this is best done in a packaging/macos/config.local.sh, e.g. with unset SIGNATURE_IDENTITY.

One thing the DMG build does as well is to modify the executables & the dylibs so that their dylib requirements are all relative to the executable paths — that’s what makes the stuff in the DMG work on machines which don’t have your Qt installed, too.

To summarize:

  • create config.local.sh & unset SIGNATURE_IDENTIY
  • run build.sh once
  • run build.sh dmg once

That used to work at some point, but I really have no clue if it still does.

Oh yikes, those are good points. I can easily implement fixes for all three of those points.

5

I was able to successfully build MKVToolNix on an ARM based mac. Thank you.

1 Like
6

I am on macOS Sequoia 15.5, and used a Mac mini M4 Pro for the build.

  1. I needed a few modifications to produce an arm64 binary, I’m listing them below. It would be good to fix these upstream.
  2. The MacPorts GUI app is missing icons and might be broken in other ways as well. Furthermore, those using homebrew may have conflicts when running two package managers so ideally there should be a homebrew installer as well.
  3. As a proof of concept, I made the homebrew formula work for compiling from source, and it produced a working GUI application. However, the formula would most likely not be accepted for the GUI application. For those, they have casks.
  4. Homebrew uses a feature called “Casks” to install graphical user interface (GUI) applications, but those cannot be built from source. Not a problem per se. There is already a cask repacking the macOS binary from the MKVToolNix website. That cask could use a universal (“fat”) binary (combining arm64 and arch x86_64) and that would be a pretty good way to distribute the program in future. Binaries in casks must be signed.

arm64 binaries can be produced on Intel-based machines as well (Building a universal macOS binary | Apple Developer Documentation). The easy way to (building both architectures at the same time) fails due to some assembly code in GMP. The two architectures must be built separately, then combined. But if two separate binaries could be published on the website that’d be a good stopgap solution. In theory, you only have to add ‘-arch arm64’ to CFLAGS, CXXFLAGS, and LDFLAGS in config.sh for instance.

Here is the list of modifications I had to make to build on my Mac. I will also list the errors I fixed with them.

  1. Create include directory in home: mkdir -p $HOME/opt/include
  2. Comment out -no-rpath in build_qt in packaging/macOS/build.sh
  3. Create packaging/macOS/config.local.sh
    export CFLAGS="$CFLAGS -Wno-int-conversion -Wno-incompatible-pointer-types"
export CXXFLAGS="$CXXFLAGS -Wno-int-conversion -Wno-incompatible-pointer-types"
  4. Update packaging/macOS/specs.sh to change to dead links:
    https://archives.boost.io/release/1.85.0/source/boost_1_85_0.tar.bz2
    https://github.com/madler/zlib/releases/download/v1.3.1/zlib-1.3.1.tar.xz

The errors I got in step 1 was:

clangclang: : clang: clang: error: error: error: no such include directory: '/Users/mjuhasz/opt/include' [-Werror,-Wmissing-include-dirs]no such include directory: '/Users/mjuhasz/opt/include' [-Werror,-Wmissing-include-dirs]
   error: no such include directory: '/Users/mjuhasz/opt/include' [-Werror,-Wmissing-include-dirs]no such include directory: '/Users/mjuhasz/opt/include' [-Werror,-Wmissing-include-dirs]

In step 2:

./configure: line 8931: 58518 Abort trap: 6           "$QMAKE6" -makefile -nocache $QMAKE_SPEC configure_non_gui.pro 2>&5 > /dev/null./configure: line 9130: 58521 Abort trap: 6           "$QMAKE6" -makefile -nocache $QMAKE_SPEC configure.pro 2>&5 > /dev/null./configure: line 8931: 58524 Abort trap: 6           "$QMAKE6" -makefile -nocache $QMAKE_SPEC configure.pro 2>&5 > /dev/nullno: not all of the required Qt6 modules were found (needed: core gui widgets network concurrent svg multimedia)configure: error: The Qt library version >= 6.2.0 is required for building MKVToolNix.

Step 3:

gatomic.c:392:10: error: incompatible integer to pointer conversion passing 'gssize' (aka 'long') to parameter of type 'gpointer' (aka 'void *') [-Wint-conversion]
     392 |   return g_atomic_pointer_add ((volatile gpointer *) atomic, val);
7

The thing that there are no icons in the menu bar is because of a change in QT. See Release Notes Qt 6.7.3:
“a2aa1f81a81 Determine Qt::AA_DontShowIconsInMenus default value based on platform The default value of Qt::AA_DontShowIconsInMenus is now determined based on the platform. On macOS icons will not show by default. To override, use QAction.iconVisibleInMenu for individual menu actions, or set Qt::AA_DontShowIconsInMenus to false.”

So just use QT 6.7.2 or older if you want to have the icons or change the source code. For this reason I have used QT 6.7.2 for the MKVToolNix 93.0 build I shared in an other thread.

8

@mjuhasz thanks for the report. I’m not really willing to spend a lot of additional time (if any) on figuring out how to actually build a universal binary, especially given that I couldn’t test its arm64 portion at all.

I am willing to integrate required changes to my build scripts and would welcome pull requests.

9

I’ve finally managed to upgrade my macOS VM to something newer than Monterey (getting the right CPU type so that the macOS kernel doesn’t hang on boot sucks so hard). Meaning I could finally upgrade XCode, and that in turn means I can upgrade Qt to something newer. I might also look into building a universal app.

Note, though, that Apple sunsetting support for x86 still means that’ll also be the end of binaries provided by myself. This is a different issue than Rosetta support: universal binaries will remove the need for Rosetta. But once Apple makes new macOS releases ARM only I won’t be able to run them anymore, meaning I won’t be able to build anything for macOS anymore. Looking around the internet I found this article that states that the next macOS release, Tahoe, will likely the last one running on Intel machines. That’ll likely give me two years, maybe three. Maybe not.

macOS users who want to keep using current MKVToolNix releases will have to step up then.

1 Like
10

I tried to build it for MacOS arm64, after a long process of build and compile, it showed the message: Done after 02:44.613. Enjoy :slight_smile:
But i could not find the mkvtoolnix.app in mkvtoolnix/packaging/macos folder. It seems that the build completed but did not reach the bundling step. I am nout sure where else to find the output file or whatelse I am missing.
Any advice?

11

After running the script you should run it again with dmg as argument. For example ./build.sh dmg

If you are successful the dmg file should be at ~/tmp/compile if I remember correctly.

Currently I can’t compile it because I don’t have access to arm hardware but I will be able to do it in 3 weeks.

12

Boom. Got it - all done. I have the v.94

13

If anyone starts making good compiles, please link.

v92 is the last working version. (I am using Intel Macs, on Sonoma.)

v94 and v95 both fail. All they do is produce a zero length output file.

If you need me to test one, let me know.

14

Somehow I can’t compile v95 I get an compiler error.

src/input/r_qtmp4.cpp:955:32: fatal error: no template named ‘bit_cast’ in namespace ‘std’; did you mean ‘fmt::detail::bit_cast’?
m_display_matrix[i][j] = std::bit_cast<int32_t>(get_uint32_be(&mvhd.display_matrix[i][j]));

/Users/test/tmp/compile/mkvtoolnix-95.0/lib/fmt/include/fmt/format.h:246:22: note: ‘fmt::detail::bit_cast’ declared here
FMT_CONSTEXPR20 auto bit_cast(const From& from) → To {

15

I’ve already fixed that after the release in the following two commits: 1, 2

16

@mbunkus - thanks. Changed CXXFLAGS from 17 to 20 - all works fine. I have uploaded the latest silicon version to the other thread in case anyone needs it.
Or perhaps you would like to post the download link under the macOS download section?

17

This may all be known, or, maybe in error, but….

The developer of qownnotes (Patrizio Bekerle) has no Mac. Until recently, he also had no Mac build. However, using github actions and an after build script, he has a universal binary that works on Intel and Apple Silicon now. This is done without any Mac at all. I helped him resolve some remaining bugs, however, it sounds as if the manual builds already work for mkvtoolnix so there shouldn’t be any. So, the MacOS build is done automatically he does nothing now.

You may (or may not) be able to do the same (or want to). His project is uses QT also. Just in case it helps or provides some useful info.

18

Welcome, and thanks for the information. I’m really not interested in going back to Github for anything these days, and I have just as little desire to spend even more time on building on macOS than I’ve already done over the years. I’m quite happy to see my commitment to macOS end in the foreseeable future, to be quite honest.

21

I was able yesterday to build v94 from the MacPorts site (latest version I could find on there). I am not a Dev (at least not for over 25 years) but it was still pretty straightforward. Not sure what is needed to update it to v95 (or later).

This built a “.app” version, not a DMG and the app is tiny (248k) so I assume it is relying on a lot of stuff that was installed during the build(?).

With a small amount of testing it appears to run okay.

22

With the following changes, I was able to build MKVToolNix (from the v96 tag) on Sequoia 15.7.1 with an M4 Max:

  1. Clone the source from Codeberg, replacing XX.X with the latest stable release (in my case v96)
git clone https://codeberg.org/mbunkus/mkvtoolnix --tag release-XX.X && cd "$_/packaging/macos"
  1. Create a config.local.sh file next to the config.sh file, with the following contents:
export SIGNATURE_IDENTITY=""
  1. Change this line inside of build.sh within the build_qt function
- build_tarball command "make DESTDIR=TMPDIR install"
+ build_tarball command "cmake --install . --prefix 'TMPDIR$TARGET'"
  1. Run ./build.sh, followed by ./build.sh dmg
  2. Navigate to ~/tmp/compile to find the MKVToolNix-XX.X.dmg file, which you can copy to another location or install from directly
  3. Once you’ve copied the dmg or installed the program directly, you can clean up the build folders (if you have no other use for them):
    • ~/tmp/compile/
    • ~/tmp/opt/

Feel free to ask any questions if you need any help getting the building to function properly.
I can also upload a signed + notorized version of the dmg & .app at a later date, feel free to remind me in a month or two :smiley:

1 Like