Thanks to Bug 1349912 we do actually have pthread in the MinGW Windows build, but lots of subprojects have windows configs that say they don't. These include (at least): - libvpx - libaom We should try turning pthread on and see if this breaks things. In particular this is desirable because redefining the macro with a new value results in a warning-as-error.

I know I need to correct the configuration generation for both libraries, but do you have any guesses if flipping this could cause problems in the library? I'm not sure who owns libvpx, so feel free to redirect...

I wouldn't expect problems. They both just implement their own pthread emulation on top of the win32 thread api, so using mingw's implementation instead should still work, possibly better. I suggest just trying it. One thing I noticed in aom/vpx_thread.h is that MAX_DECODE_THREADS is limited to 8 in part because of "not enough semaphors...on windows". https://dxr.mozilla.org/mozilla-central/source/media/libvpx/libvpx/vpx_util/vpx_thread.h#24 Hopefully mingw can manage at least that many. :)

Comment on attachment 8916789 [details] Bug 1406542 Enable PTHREAD for vpx and aom under MinGW because we do in fact have them. https://reviewboard.mozilla.org/r/187842/#review197840 Looks reasonable to me. Thanke for updating the source generation scripts!

Pushed by rgiles@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/2fa7cfb4ce84 Enable PTHREAD for vpx and aom under MinGW because we do in fact have them. r=rillian