Default mingw32 compilation is broken by atomic

[cehoyos]

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.

[cehoyos]

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@…]

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.

[heleppkes]

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.

[cehoyos]

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

[michael]

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