Help Obtaining Latest mkvmerge Binary for Linux Server

Help
1

Hello,
First post, long time lurker :eye:

Like most of you here, I like to keep my software up-to-date. Unfortunately my server does not give me root access to update mkvtoolnix myself. I’m currently stuck on mkvmerge v79.0 ('Funeral Pyres') 64-bit

The server is running

Distributor ID:    Debian
Description:    Debian GNU/Linux 10 (buster)
Release:    10
Codename:    buster

I run some tools in a venv on the server, so I can place the mkvmerge binary in the /bin folder.

The problem I face is I use macOS which is arm64 based. I can’t simply copy over my installed binary as it’s not compatible with the server.

I’ve had limited success with compiling the x86_64 binary with docker. However, it only obtains up to mkvmerge v81.0 ('Milliontown') 64-bit, not the desired mkvmerge v84.0 ('Sleeper') 64-bit
I guess that’s because

Older Debian versions: the repositories for older releases still exist but aren’t updated anymore:

The buster repo only goes up to 81.

I’ve also obtained the Linux Flatpak image, extracted it with binwalk -e MKVToolNix_GUI-84.0-x86_64.AppImage. I can browse to the resulting mkvmerge binary but it does not run on the server and displays the following:

./mkvmerge
./mkvmerge: error while loading shared libraries: libboost_filesystem.so.1.85.0: cannot open shared object file: No such file or directory

file mkvmerge 
mkvmerge: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=6f7205f3e5e62fac06935038cc35c7eb110fb7a4, for GNU/Linux 3.2.0, stripped

I’ve also made a Debian Buster Live USB to try and extract it that way, but the resulting file wouldn’t execute on the server either.

Maybe it’s simply not possible on my server without libboost installed.

So, if anyone has a solution I’d really appreciate the help!

2

Welcome!

The AppImage contains most libraries required to run MKVToolNix including libboost apart from certain system-level libraries that are always expected to be there (mostly glibc, X11, but also pulse audio & others). However, if you extract the files from the AppImage you’ll have to set the LD_LIBRARY_PATH environment variable to point to the extracted squashfs-root/usr/lib directory manually (this is done automatically when you run the AppImage directly instead of extracting the files from it).

For example, assuming you have the AppImage extracted into $HOME/appimage:

[0 mosu@sweet-chili ~] docker run -ti --rm --volume $HOME:/mnt debian:10 /bin/bash
root@644082b52247:/# apt update
[[…output omitted…]]
root@644082b52247:/# apt install locales
[[…output omitted…]]
root@644082b52247:/# echo en_US.UTF-8 UTF-8 >> /etc/locale.gen
root@644082b52247:/# locale-gen
Generating locales (this might take a while)...
  en_US.UTF-8... done
Generation complete.
root@644082b52247:/# export LD_LIBRARY_PATH=/mnt/appimage/squashfs-root/usr/lib
root@644082b52247:/# /mnt/appimage/squashfs-root/usr/bin/mkvmerge -o out.mkv /mnt/v.opus
mkvmerge v84.0 ('Sleeper') 64-bit
'/mnt/v.opus': Using the demultiplexer for the format 'Ogg/OGM'.
'/mnt/v.opus' track 0: Using the output module for the format 'Opus'.
The file 'out.mkv' has been opened for writing.
The cue entries (the index) are being written...
Multiplexing took 0 seconds.
root@644082b52247:/# exit

Generally you wouldn’t have to extract the AppImage if you want to run mkvmerge from the AppImage as you can symlink it to mkvmerge & run it that way: the AppImage’s entrypoint script checks the name under which it was called, and if it’s mkvmerge, mkvinfo, mkvpropedit or mkvextract it’ll run the corresponding CLI program instead of the GUI:

[0 mosu@sweet-chili ~] ln -s MKVToolNix_GUI-84.0-x86_64.AppImage mkvmerge
[0 mosu@sweet-chili ~] ./mkvmerge --help | head
mkvmerge -o out [global options] [options1] <file1> [@option-file.json] …

 Global options:
  -v, --verbose            Increase verbosity.
  -q, --quiet              Suppress status output.
  -o, --output out         Write to the file 'out'.
  -w, --webm               Create WebM compliant file.
  --title <title>          Title for this destination file.
  --global-tags <file>     Read global tags from an XML file.

However, that requires the FUSE kernel module to be loaded. And if I understand you correctly, you’re running a Mac, and that combination won’t be able to run the AppImage directly. Therefore running inside Docker is one idea; the other is using the macOS DMG I provide (it contains the CLI apps as well).

If you’re into using Docker, you might want to look into the existing MKVToolNix Docker image by Jocely Le Sage; it’s pretty good (but focused on running the GUI, too).

3

Thanks very much or your reply.

I had a play with the docker you suggested, but it compiles for Alpine Linux.

I’m going to try the symlink option, calling the mkvmerge cli from within the Appimage.

This concept is wild to me, but if it works that would be a nice approach.

I’ll keep you posted!

4

Thank you, this worked! I also had to modify the PATH environment variable within the virtual environment to prioritize the bin directory of the virtual environment.

I can now run mkvmerge anywhere in the venv and get mkvmerge v84.0 ('Sleeper') 64-bit. This will make upgrading super easy!

Please consider mkvmerge v85.0 ('Understanding') 64-bit to commemorate our shared success.

Very happy! Thank you!