configure: WARNING: mingw.thread.h: present but cannot be compiled

[Reino]

Hello,

I'm trying to cross-compile (on Windows XP using Cygwin, MinGW 8.0.2 and GCC 11.2.0 (built using this MinGW-w64 buildscript)) libopenmpt ('libopenmpt-0.6.3+release.autotools.tar.gz') for inclusion in FFmpeg. So on WinXP in a Linux environment for WinXP.

mingw-std-threads was just a matter of...

Code Select Expand

git clone https://github.com/meganz/mingw-std-threads.git
cd mingw-std-threads_git
for header in *.h; do
  install -m644 ${header} ${mingw_w64_x86_64_prefix}/include/${header}
done

However, libopenmpt's 'configure' can't seem to use it. The following is from its 'config.log':

Code Select Expand

configure:19936: checking mingw.thread.h usability
configure:19936: i686-w64-mingw32-g++ -std=c++17 -c -DWINVER=_WIN32_WINNT_WINXP -municode -mthreads -fvisibility=hidden -Wall  conftest.cpp >&5
In file included from conftest.cpp:67:
[...]cross_compilers/mingw-w64-i686/i686-w64-mingw32/include/mingw.thread.h:330:24: error: 'class mingw_stdthread::thread' conflicts with a previous declaration
  330 | using mingw_stdthread::thread;
      |                        ^~~~~~
In file included from [...]cross_compilers/mingw-w64-i686/i686-w64-mingw32/include/c++/11.2.0/thread:43,
                 from [...]cross_compilers/mingw-w64-i686/i686-w64-mingw32/include/mingw.thread.h:28,
                 from conftest.cpp:67:
[...]cross_compilers/mingw-w64-i686/i686-w64-mingw32/include/c++/11.2.0/bits/std_thread.h:62:9: note: previous declaration 'class std::thread'
   62 |   class thread
      |         ^~~~~~
configure:19936: $? = 1
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME "libopenmpt"
| #define PACKAGE_TARNAME "libopenmpt"
| #define PACKAGE_VERSION "0.6.3+release.autotools"
| #define PACKAGE_STRING "libopenmpt 0.6.3+release.autotools"
| #define PACKAGE_BUGREPORT "https://bugs.openmpt.org/"
| #define PACKAGE_URL "https://lib.openmpt.org/"
| #define PACKAGE "libopenmpt"
| #define VERSION "0.6.3+release.autotools"
| #define STDC_HEADERS 1
| #define HAVE_SYS_TYPES_H 1
| #define HAVE_SYS_STAT_H 1
| #define HAVE_STDLIB_H 1
| #define HAVE_STRING_H 1
| #define HAVE_MEMORY_H 1
| #define HAVE_STRINGS_H 1
| #define HAVE_INTTYPES_H 1
| #define HAVE_STDINT_H 1
| #define HAVE_UNISTD_H 1
| #define HAVE_DLFCN_H 1
| #define LT_OBJDIR ".libs/"
| #define _FILE_OFFSET_BITS 64
| #define MPT_SVNURL "https://source.openmpt.org/svn/openmpt/tags/libopenmpt-0.6.3"
| #define MPT_SVNVERSION "17274"
| #define MPT_SVNDATE "2022-04-24T13:18:24.140099Z"
| #define MPT_PACKAGE true
| #define MPT_WITH_ZLIB /**/
| #define MPT_WITH_MPG123 /**/
| #define MPT_WITH_OGG /**/
| #define MPT_WITH_VORBIS /**/
| #define MPT_WITH_VORBISFILE /**/
| #define HAVE_CXX17 1
| /* end confdefs.h.  */
| #include <stdio.h>
| #ifdef HAVE_SYS_TYPES_H
| # include <sys/types.h>
| #endif
| #ifdef HAVE_SYS_STAT_H
| # include <sys/stat.h>
| #endif
| #ifdef STDC_HEADERS
| # include <stdlib.h>
| # include <stddef.h>
| #else
| # ifdef HAVE_STDLIB_H
| #  include <stdlib.h>
| # endif
| #endif
| #ifdef HAVE_STRING_H
| # if !defined STDC_HEADERS && defined HAVE_MEMORY_H
| #  include <memory.h>
| # endif
| # include <string.h>
| #endif
| #ifdef HAVE_STRINGS_H
| # include <strings.h>
| #endif
| #ifdef HAVE_INTTYPES_H
| # include <inttypes.h>
| #endif
| #ifdef HAVE_STDINT_H
| # include <stdint.h>
| #endif
| #ifdef HAVE_UNISTD_H
| # include <unistd.h>
| #endif
| #include <mingw.thread.h>
configure:19936: result: no
configure:19936: checking mingw.thread.h presence
configure:19936: i686-w64-mingw32-g++ -E -std=c++17  conftest.cpp
configure:19936: $? = 0
configure:19936: result: yes
configure:19936: WARNING: mingw.thread.h: present but cannot be compiled
configure:19936: WARNING: mingw.thread.h:     check for missing prerequisite headers?
configure:19936: WARNING: mingw.thread.h: see the Autoconf documentation
configure:19936: WARNING: mingw.thread.h:     section "Present But Cannot Be Compiled"
configure:19936: WARNING: mingw.thread.h: proceeding with the compiler's result
configure:19936: checking for mingw.thread.h
configure:19936: result: no

I'm not a professional coder, so I was wondering if anyone can tell me how I can make it use mingw-std-threads.

On a side-note: Initially I was planning on using 'libopenmpt-0.4.30+release.autotools.tar.gz', because...

https://lib.openmpt.org/libopenmpt/2020/05/24/releases-0.5.0-0.4.13-0.3.22/:

[Regression] Windows XP and Windows Vista are no longer supported.

...but I saw someone else's script doing:

Code Select Expand

CFLAGS="$CFLAGS -DWINVER=_WIN32_WINNT_WINXP" CXXFLAGS=$CXXFLAGS "-DWINVER=_WIN32_WINNT_WINXP" ./configure [...]

I haven't tried it out yet, but would that really be enough to restore WinXP compatibility, or would it be best to stick to 'libopenmpt-0.4.30+release.autotools.tar.gz'?

[manx]

I'm trying to cross-compile (on Windows XP using Cygwin, MinGW 8.0.2 and GCC 11.2.0 (built using this MinGW-w64 buildscript)) libopenmpt ('libopenmpt-0.6.3+release.autotools.tar.gz') for inclusion in FFmpeg. So on WinXP in a Linux environment for WinXP.

mingw-std-threads was just a matter of...

Code Select Expand

git clone https://github.com/meganz/mingw-std-threads.git
cd mingw-std-threads_git
for header in *.h; do
  install -m644 ${header} ${mingw_w64_x86_64_prefix}/include/${header}
done

However, libopenmpt's 'configure' can't seem to use it. The following is from its 'config.log':

Code Select Expand

configure:19936: checking mingw.thread.h usability
configure:19936: i686-w64-mingw32-g++ -std=c++17 -c -DWINVER=_WIN32_WINNT_WINXP -municode -mthreads -fvisibility=hidden -Wall  conftest.cpp >&5
In file included from conftest.cpp:67:
[...]cross_compilers/mingw-w64-i686/i686-w64-mingw32/include/mingw.thread.h:330:24: error: 'class mingw_stdthread::thread' conflicts with a previous declaration
  330 | using mingw_stdthread::thread;
      |                        ^~~~~~
In file included from [...]cross_compilers/mingw-w64-i686/i686-w64-mingw32/include/c++/11.2.0/thread:43,
                 from [...]cross_compilers/mingw-w64-i686/i686-w64-mingw32/include/mingw.thread.h:28,
                 from conftest.cpp:67:
[...]cross_compilers/mingw-w64-i686/i686-w64-mingw32/include/c++/11.2.0/bits/std_thread.h:62:9: note: previous declaration 'class std::thread'
   62 |   class thread
      |         ^~~~~~
configure:19936: $? = 1
...


I'm not a professional coder, so I was wondering if anyone can tell me how I can make it use mingw-std-threads.

I'm not familiar with that MinGW build script, however from a quick glance, it looks to me like it will build a GCC with POSIX threading model, in which case you do not need mingw-std-threads.

Can you show the output of

Code Select Expand

i686-w64-mingw32-g++ -v please to verify?

Did you run into any errors when not providing mingw-std-threads?

On a side-note: Initially I was planning on using 'libopenmpt-0.4.30+release.autotools.tar.gz', because...

https://lib.openmpt.org/libopenmpt/2020/05/24/releases-0.5.0-0.4.13-0.3.22/:

[Regression] Windows XP and Windows Vista are no longer supported.

...but I saw someone else's script doing:

Code Select Expand

CFLAGS="$CFLAGS -DWINVER=_WIN32_WINNT_WINXP" CXXFLAGS=$CXXFLAGS "-DWINVER=_WIN32_WINNT_WINXP" ./configure [...]

I haven't tried it out yet, but would that really be enough to restore WinXP compatibility, or would it be best to stick to 'libopenmpt-0.4.30+release.autotools.tar.gz'?

We did add back Windows XP support in 0.6.0. Looks like we did forget to mention it in the changelog

So, 0.6 should be fine for you, and is more likely to get fixed if something does not work correctly (especially for platforms like Windows XP that get very few testing, if at all, nowadays).

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.

[Reino]

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:

Code Select Expand

  --threads=LIB               compile with support for thread LIB (winpthreads,
                              pthreads-w32, disable) [pthreads-w32]
[...]

if [[ "$thread_lib" = 'winpthreads' ]]; then
  enable_threads="--enable-threads=posix"
fi
[...]

if [[ -z "$thread_lib" ]]; then
  thread_lib='pthreads-w32'
fi
[...]

while true; do
  case $1 in
    [...]
    --threads=* ) thread_lib="${1#*=}"; shift ;;
    [...]
  esac
done

Can you show the output of

Code Select Expand

i686-w64-mingw32-g++ -v please to verify?

Code Select Expand

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)

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:

Code Select Expand

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.

We did add back Windows XP support in 0.6.0. Looks like we did forget to mention it in the changelog

So, 0.6 should be fine for you, and is more likely to get fixed if something does not work correctly (especially for platforms like Windows XP that get very few testing, if at all, nowadays).

That's good to hear.
I guess I'm one of the few people left spending time on trying to compile WinXP compatible FFmpeg binaries and as far as I know I'm the only one left that adds compatibility for old non-SSE2 cpus on top (like my own AMD Athlon XP 3200+). So yes, I can imagine libopenmpt doesn't get tested that much on WinXP anymore nowadays.

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?

[manx]

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:

Code Select Expand

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:

Code Select Expand

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.

[manx]

Not sure what that means for libopenmpt. I will maybe have to deprecate mingw-std-threads, and probably rephrase the warning for GCC>=11.

Can you try to build libopenmpt 0.6.4-pre.1 (available at https://builds.openmpt.org/) with mingw-std-threads? I changed the detection of mingw-std-threads to detect mingw.mutex.h instead of mingw.thread.h, which may work-around the GCC11 change. Source snapshot should be available in an hour or so at https://builds.openmpt.org/builds/auto/libopenmpt/src.autotools/0.6.4-pre.1/.

[Reino]

and it looks like GCC11 just broke mingw-std-threads by providing a std::thread implementation itself, which does NOTHING.

Just curious, the previous GCC10 doesn't have this issue?

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.

To be absolutely clear, that means -D_WIN32_WINNT=_WIN32_WINNT_WINXP for CFLAGS as well as CXXFLAGS?

Can you try to build libopenmpt 0.6.4-pre.1 (available at https://builds.openmpt.org/) with mingw-std-threads? I changed the detection of mingw-std-threads to detect mingw.mutex.h instead of mingw.thread.h, which may work-around the GCC11 change.

This didn't make a difference. Same 'config.log' warning-message, except now it's mentioning mingw.mutex.h instead of mingw.thread.h of course.

[manx]

and it looks like GCC11 just broke mingw-std-threads by providing a std::thread implementation itself, which does NOTHING.

Just curious, the previous GCC10 doesn't have this issue?

It looks like it, yes (https://github.com/gcc-mirror/gcc/commit/b204d7722d30f44281dea3341070223475f1cff9). However, in the end, the true GCC bug is not the change, but instead the fact that it does not support C++11 threading when using the win32 threading model even 11 years after the finalization oft that standard. And I frankly do not see that changing anytime soon.

For the long term, I suggest you look into changing to a MinGW toolchain that uses Posix threading model instead. This would highly likely imply that your binaries will need winpthreads.dll (or similar) that comes with MinGW-w64.

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.

To be absolutely clear, that means -D_WIN32_WINNT=_WIN32_WINNT_WINXP for CFLAGS as well as CXXFLAGS?

Yes.

Can you try to build libopenmpt 0.6.4-pre.1 (available at https://builds.openmpt.org/) with mingw-std-threads? I changed the detection of mingw-std-threads to detect mingw.mutex.h instead of mingw.thread.h, which may work-around the GCC11 change.

This didn't make a difference. Same 'config.log' warning-message, except now it's mentioning mingw.mutex.h instead of mingw.thread.h of course.

Too bad, was just a shot in the dark from my side.

In any case, I misremembered how we had used std::mutex. Even with win32 threading model when not using mingw-std-thread, libopenmpt will fall back to its own mutex implementation, which is thread-safe. The original plan was to remove our own implementation and rely on mingw-std-threads in libopenmpt 0.7. However, seeing that mingw-std-threads is broken since almost a year with modern GCC, I do not see this as a viable plan any more. I think I'll just remove mingw-std-threads in 0.7 instead and keep our own implementation.

0.6 of course also still has the std:mutex fallback, so building without mingw-std-threads is fine in that regard.

So, you can just build 0.6 without mingw-std-threads and ignore the warning.

[Reino]

So, you can just build 0.6 without mingw-std-threads and ignore the warning.

I've successfully built new WinXP compatible FFmpeg binaries with the appropriate C(XX)FLAGS for libopenmpt (but indeed without mingw-std-threads). So far they're working great with tracker-files I have.
Thanks for your time!

[manx]

As of libopenmpt 0.6.4-pre.2, mingw-std-threads support is now deprecated and the warning says:

Platform (Windows) supports multi-threading, however the toolchain (MinGW/GCC) does not. The resulting libopenmpt may not be thread-safe. This is a MinGW/GCC issue. You can avoid this warning by using a MinGW toolchain built with posix threading model as opposed to win32 threading model.

which may be more clear.

As of libopenmpt 0.7.0-pre.8, support for mingw-std-threads has been removed completely.