it looks to me like it will build a GCC with POSIX threading model
Not by default. See https://files.1f0.de/mingw/scripts/mingw-w64-build-r34 for example:
Using built-in specs.
COLLECT_GCC=[...]/cross_compilers/mingw-w64-i686/bin/i686-w64-mingw32-g++
COLLECT_LTO_WRAPPER=[...]/cross_compilers/mingw-w64-i686/libexec/gcc/i686-w64-mingw32/11.2.0/lto-wrapper.exe
Target: i686-w64-mingw32
Configured with: ../source/gcc-11.2.0/configure --build=i686-pc-cygwin --target=i686-w64-mingw32 --disable-shared --enable-static --disable-nls --disable-multilib --prefix=[...]/cross_compilers/mingw-w64-i686 --with-sysroot=[...]/cross_compilers/mingw-w64-i686 --with-mpc=[...]/cross_compilers/pkgs/mpc/mpc-1.2.1-i686 --with-mpfr=[...]/cross_compilers/pkgs/mpfr/mpfr-4.1.0-i686 --with-gmp=[...]/cross_compilers/pkgs/gmp/gmp-6.2.1-i686 --with-isl=[...]/cross_compilers/pkgs/isl/isl-0.24-i686 --enable-languages=c,c++ --enable-fully-dynamic-string --enable-lto
Thread model: win32
Supported LTO compression algorithms: zlib
gcc version 11.2.0 (GCC)
Thanks for clarifying.
So you are using win32 threading model, and it looks like GCC11 just broke mingw-std-threads by providing a std::thread implementation itself, which does NOTHING. See
https://github.com/meganz/mingw-std-threads/issues/79#issue-947117163. I do
not suggest using what is mentioned in the linked issue, though (see below).
Did you run into any errors when not providing mingw-std-threads?
Not yet, but I haven't finished compiling an FFmpeg binary yet, so I can't tell at the moment.
I did get the following warning (again) though near the end of libopenmpt's compilation-process:
libopenmpt/libopenmpt_impl.cpp:91:13: warning: Warning: Building libopenmpt with MinGW-w64 without std::thread support is not recommended and is deprecated. Please use MinGW-w64 with posix threading model (as opposed to win32 threading model), or build with mingw-std-threads.
91 | MPT_WARNING("Warning: Building libopenmpt with MinGW-w64 without std::thread support is not recommended and is deprecated. Please use MinGW-w64 with posix threading model (as opposed to win32 threading model), or build with mingw-std-threads.")
I'm just trying to compile FFmpeg with MODtracker support. I don't have any connection to libopenmpt other than that.
As it's a warning, is it "bad" to compile libopenmpt without a threading model?
Maybe I'm ignorant, but unlike H.264/H.265 video-encoding I can't imagine playing/processing MODtracker-files with FFmpeg (through libopenmpt) is taxing on the cpu.
Correct, this is not at all a performance consideration. libopenmpt is (currently, but may in the future) not using any multi-threading internally, however it has to initialize some global data internally on first use. In order to do that correctly, it needs to use locking (by means of C++11 thread-safe statics and std::mutex). Now, I honestly do not know if GCC can/does provide the required C++11 threadsafe statics (documentation in this area is close to non-existing) when it uses a threading model that is severely limited (and IMHO completely broken because C++11 requires proper threading support, which GCC/MinGW only provide with POSIX threading model). It certainly does not provide std::mutex though, which we also use.
Now, this can only ever be problem if some program uses libopenmpt (or in your case the ffmpeg libraries, in particular libavformat) from multiple threads at the same time. If you are only compiling the ffmpeg executables, I think this can never happen. Even if you build other programs using the built ffmpeg libraries, it is highly unlikely to ever be a problem in practice or at all.
The main purpose of the warning is to make people aware of the non-standard-compliance mess that GCC and MinGW have created surrounding C++ threading in general.
As mingw-std-threads does not work with GCC11 any more, I would consider the whole issue a mingw-std-threads bug. Now, I am not following mingw-std-threads development closely, but given that the issue has been apparently ignored for about a year now, I would not expect it to be addressed at all any time soon.
Not sure what that means for libopenmpt. I will maybe have to deprecate mingw-std-threads, and probably rephrase the warning for GCC>=11.
For the time being, plesae just build without mingw-std-threads. The warning is not as scary as it may sound.
I would use -D_WIN32_WINNT=_WIN32_WINNT_WINXP instead of -DWINVER=_WIN32_WINNT_WINXP however, as that is the officially documented variable to set for Windows XP.
If WinXP is supported again, would these flags/parameters be necessary at all?
Yes. These macros define the set an APIs available from the windows header files. By default, Windows (or MinGW) headers will provide the API for the newest Windows version. Thus, if you want to target Windows XP, you need to set it to Windows XP. libopenmpt (and other programs/libraries) will use these to detect what functionality they can use.
