Default mingw32 compilation is broken by atomic

[Carl Eugen Hoyos]

By default, FFmpeg uses w32threads if available.
The addition of "atomic" broke the default compilation on mingw32 because it does not provide MemoryBarrier, work-around is to use --disable-w32threads or --enable-pthreads.

$ ./configure

...

$ grep W32THREADS config.h
#define HAVE_W32THREADS 1
$ make libavutil/atomic.o
CC      libavutil/atomic.o
libavutil/atomic.c:101:2: Fehler: #error "Threading is enabled, but there is no implementation of atomic operations available"
common.mak:48: recipe for target 'libavutil/atomic.o' failed
make: *** [libavutil/atomic.o] Error 1

configure should at least abort if compilation cannot succeed.

[Carl Eugen Hoyos]

Work-around is to specify a value for --cpu: i486, i686, core2, corei7, corei7-avx and atom all work fine.

$ ./configure --cpu=corei7-avx
...
$ grep W32THREADS config.h
#define HAVE_W32THREADS 1
$ make libavutil/atomic.o
CC      libavutil/atomic.o
$

[lars.hammarstrand@gmail.com]

This issue also broke current xbmc master with ffmpeg master head for win32.

1. What flags do you suggest we use as work-around to best fit a general intel/amd build?
2. I take it this will be fixed someday in the future?

Thanks in advance, Lars.

[Hendrik]

Instead of looking for workarounds, i would suggest to grab a mingw-w64 toolchain, which does not lack the required features to build with atomics (contrary to its name, it can build 32 and 64-bit)

If you really must use a workaround, then simply use --cpu=i686 for configure, any older systems are hardly relevant, but even i486 should solve the issue, if you insist.

[Carl Eugen Hoyos]

The alternative trivial workaround that - afaik - cannot fail on any hardware is of course to use pthreads.

[Michael Niedermayer]

Note, a patch adding a workaround for mingw32 is welcome, i dont have mingw32 installed i think, i dont want to try to blindly add something that i couldnt test

[Michael Niedermayer]

as none of the affected users is willing to write and test a 1-2 line change for configure (adding i486 as cpu if not otherwise set), this certainly is not priority=important (none of the affected users care or everyone switched to ming64)

[Dave Yeo]

Note that OS/2 is broken exactly the same way when configured with --enable-os2threads. Same workarounds apply

[Michael Niedermayer]

"Fixed" in f5dae4894d1078ac8a56026e9ad55c2f0575ce1e
Patch for better fix is of course welcome