Closed robUx4 closed 9 months ago
As for mkvtoolnix, @mbunkus you're the one to decide. I suppose on desktop you have the same of more recent OS support than VLC, so it should end with the same availability.
VLC 4.0 is also very likely going to switch to Qt6 which requires a C++17 compiler.
We currently don't have contribs that use C++17 apart from glslang, but I think it's not used as a library.
Thanks for collecting all this info; this is great. As for MKVToolNix: I already require C++17 for it, have been for quite a while.
As for C++17 support on Linux: this is a bit tricky to answer. There are three different eco systems wrt. long-term supported distributions:
For the RHEL-based distros you have the option of using the devtools
packages. RedHat provides current compilers & libstdc++
for them. Therefore you can pretty much always use modern C++, including C++17. The question is usually if the other required libraries are available in new-enough versions, or if you need to bundle them. This even applied to the oldest supported release, RHEL 7, and that one falls out of regular support this year. RHEL 8 & 9 are very much OK wrt. C++17.
For Debian/Ubuntu: Ubuntu 18.04 (regular support ended in April 2023) has gcc 7.4.x. Debian oldoldstable (buster; regular support ended in 2022, LTS ends in June 2024) has 8.3.x.
Not sure about the SuSE eco system, but from past experience I seem to remember they always have up to date compilers available.
In short, I don't see any Linux distro/version that we need to worry about wrt. C++17 support.
VLC 4.0 officially requires a C++17 compiler for C++ code. So we can make the switch.
https://code.videolan.org/videolan/vlc/-/merge_requests/4765
As years go by we can gradually update the minimum required/target C++ version. libebml/libmatroska are use mostly by VLC and mkvtoolnix. Following this discussion https://github.com/Matroska-Org/libebml/pull/207#discussion_r1443783440 I did a little digging.
In this chart we can tell which compiler version has which C++17 feature in what version. With gcc 7 and Clang 4 we have proper C++17 support.
Current VLC 3.0 will not switch to libebml 2.0. The next version of VLC will have support for both. The current system+compiler are:
The gcc and clang restrictions actually depend on the target OS. Theoretically any other OS could be supported as long as these compilers are supported. In reality VLC uses gcc extensions and will hardly build with non-gcc compilers (I maintain a version that builds with MSVC which doesn't fully support C11, nor extensions like typeof()). And thus you need gcc/clang, and it's likely tied to your exotic system.
The consequences of switching to C++17 means VLC would not be able to build with libebml/libmatroska on such system. It would not lose Matroska support as long as libavformat is compiled. So let's see on which system that could be the case:
Windows ✅
It requires mingw-w64 v5 which was tagged in 2016. At that time gcc 6 was out but not gcc 7. However we are soon going to require the posix thread model from the toolchain (so we have proper threading in C++ which is not done for win32 thread model). This is the default in mingw LLVM toolchains but not for gcc, so much that we'll need to build our own toolchain for that. So in reality you either have to use clang or a custom build gcc. The LLVM mingw builds started in 2018 and was using clang 6 which was the latest version at that time.
Summary: we don't care too much about the gcc version and clang support always includes clang 4.
macOS ✅
The oldest clang for 10.11 is clang 7, so above clang 4.
iOS9 ✅
Requires XCode 12, which started in OS X 10.15. As seen above it's covered.
Android 4.1 / v16 ✅
That implies the r8b NDK. However the minimum NDK to build VLC 4.0 for Android is 25 which uses LLVM/clang 14.
Linux ✅
That's more complicated. There might be supported distros that still build with gcc older than 5 which was out in 2015. But these distros will likely never get VLC 4.0. So we don't need to worry about these distros. As said above, if anything they can still handle Matroska files through libavformat, just with less Matroska features.