The resource file has reached a size at which the C++ compiler
exhausts available virtual memory on some 32-bit architectures.
On Windows & macOS the GUI will look for the file in
`<folder_with_executables>/data/qt_resources.rcc`, and in the
directory set with `configure`'s `--datadir` parameter on other
systems (which usually means `/usr/share/mkvtoolnix`). The `install`
build system commands installs it into that folder.
gcc's implementation of the C++17 file system library doesn't support
UNC paths of style `\\?\…` on Windows. There doesn't seem to be any
progress towards implementing support for it.
Fixes#3058. See also #2916.
For Ubuntu 22.04 and later the GUI will be built with Qt 6 instead of
Qt 5 due to severe issues with 22.04, Qt 5 and high DPI displays. See
issue #3358 for more information.
Unfortunately Debian's package tooling isn't powerful enough to
express complex dependencies, and it cannot express things based on
the distribution & version the package is built for. The packaging for
Qt 6 requires different libraries than the packaging for Qt 5,
obviously.
The only thing one could do in a single `control` file is using ORed
dependencies such as `libqt6svg6 | libqt5svg5`, but that can lead to
situations where the user has `libqt5svg5` installed, doesn't have
`libqt6svg6` installed, and then MKVToolNix built with Qt 6 will
install just fine but all the icons will be missing as it cannot load
the SVG plugin dynamically.
Therefore the `control` & `rules` files are now built from templates,
and a Ruby script called `packaging/debian/create_files.rb` is used to
create the files from their templates. The user can specify the
distribution & version to create for with command line arguments. If
not specified, the script will attempt to guess the distribution &
version it's running on.
Only Debian ≥ 10 & Ubuntu ≥ 20.04 are supported, same as before.
For some reason Debian's own fmt throws an exception on the call of
`fmt::format("{}", fmt::join(…))` on the armhf architecture, while the
same code works fine on Debian 11 on other architectures (i386,
amd64). The same code works fine on armhf with Debian 10's fmt & my
own bundled version, so just the latter one.
The next stable release of Debian, version 11 "Bullseye", will ship
with a gcc version that produces an "internal compiler error"
segmentation fault when compiling current versions of MKVToolNix. This
error has been fixed in gcc upstream as well as the gcc in Debian
testing, but it won't be backported to the one in Bullseye.
There are two possible workarounds:
1. Compile with clang instead (this is what this commit does)
2. Compile with gcc 9 which Bullseye also ships
As I've been using clang in parallel to gcc for years, I've opted to
compile with it instead of the older gcc 9 for Bullseye.
Ubuntu releases don't suffer from this issue:
* 20.04 comes with gcc 9.3.0
* 20.10 & 21.04 come with gcc 10.3
I know compilation fails in the multi-precision library with 1.60.0,
the previous requirement. The oldest OS I still support is CentOS 7,
which has 1.69 via EPEL. CentOS 8 is next which comes with 1.66.0, and
that compiles fine. So let's take that as the new baseline.
