Opened 5 years ago

Closed 4 years ago

#2363 closed defect (fixed)

Default mingw32 compilation is broken by atomic

Reported by: cehoyos Owned by:
Priority: normal Component: avutil
Version: git-master Keywords: win regression
Cc:, Blocked By:
Blocking: Reproduced by developer: no
Analyzed by developer: no


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.

Change History (10)

comment:1 Changed 5 years ago by downuse

  • Cc added

comment:2 Changed 5 years ago by KuroiTsuki

  • Cc added

comment:3 Changed 5 years ago by 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

comment:4 Changed 5 years ago by

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.

comment:5 Changed 5 years ago by 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.

comment:6 Changed 5 years ago by cehoyos

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

comment:7 Changed 5 years ago by 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

comment:8 Changed 5 years ago by michael

  • Priority changed from important to normal

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)

comment:9 Changed 5 years ago by dryeo

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

comment:10 Changed 4 years ago by michael

  • Resolution set to fixed
  • Status changed from new to closed

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

Note: See TracTickets for help on using tickets.