Can't compile

[jpsdr]

Hello. It's been a little time while i've tried to compile ffms2, but i've always succed until now. First i compile (and install) last stable release of ffmpeg (2.7.2), everything is Ok. I've got the last release you've provided (2.21). When i configure everything is Ok, and when i try to compile (GCC 4.8.4) i have a gcc error message in src/core/videosource.cpp line 153, saying that "std::thread has not been declared". As i'm doing exactly the same things i was doing when i've succefully compiled before, i don't understand what's wrong.

[qyot27]

Windows builds of GCC can no longer use win32 threading for FFMS2, it has to be C++11 threads (as provided by passing --enable-threads=posix when configuring GCC + MinGW-w64's winpthreads implementation).

Because this really only could happen on Windows due to the division between threading libraries/options, unless GCC 4.8 is possibly too old, but I doubt that.

[jpsdr]

Thanks for answer, but as i'm far from being an expert with GCC and configuration stuff, here the script i was using to compile, can you tell me what option to put/add to compile now ?

cd ffms2-stable/Build32_x264 LDFLAGS="-static" \ PKG_CONFIG_PATH="C:/MinGW/local-x264_x86/posix/lib/pkgconfig" \ CFLAGS="-Wno-deprecated-declarations" \ CXXFLAGS="-Wno-deprecated-declarations" \ ../configure --prefix=C:/MinGW/local-x264_x86/posix --build="i686-w64-mingw32" --enable-static --disable-shared make make install make clean

[qyot27]

When you're in the MSys2 shell, try to detect the presence of i686-w64-mingw32-gcc-posix, and if it exists, add CC=i686-w64-mingw32-gcc-posix CXX=i686-w64-mingw32-g++-posix to the environment variables; if you're not using MSys2, then there's not much I can do to propose a solution because it's too unpredictable. I cross-compile 99% of the time, so my working environment is on Linux and I maintain a guide on how that particular toolchain is set up here.

[dwbuiten]

it has to be C++11 threads

Perhaps a configure check should be added.

[jpsdr]

The result of gcc -v of the gcc version i'm using results in : Using built-in specs. COLLECT_GCC=c:\MinGW\bin\gcc.exe COLLECT_LTO_WRAPPER=c:/mingw/bin/../libexec/gcc/i686-w64-mingw32/4.8.4/lto-wrapper.exe Target: i686-w64-mingw32 Configured with: ../src/configure --prefix=/mingw_new --with-sysroot=/mingw_new --with-build-sysroot=/mingw_new --build=i686-w64-mingw32 --target=i686-w64-mingw32 --enable-targets=all --with-gmp=/mingw_new/sup --with-mpfr=/mingw_new/sup --with-mpc=/mingw_new/sup --with-isl=/mingw_new/sup --with-cloog=/mingw_new/sup --disable-isl-version-check --disable-cloog-version-check --with-host-libstdcxx='-lstdc++ -lsupc++' --disable-shared --enable-static --disable-bootstrap --disable-win32-registry --enable-threads=win32 --enable-languages=c,c++ --enable-version-specific-runtime-libs --enable-multilib --disable-rpath --with-system-zlib --disable-werror --disable-nls --enable-decimal-float --disable-debug --enable-lto --enable-64bit --enable-largefile --enable-fully-dynamic-string --enable-sjlj-exceptions --enable-libssp --enable-libgomp Thread model: win32 gcc version 4.8.4 (multilib.generic.Komisar) (GCC)

So, if i've understood properly, it's not good anymore. For now, i've been able at least to compile 2.20.

Ok. Thanks for these informations.

[jpsdr]

On the other hand, i can compile x264 with either posix or win32 threads.

There is this on the configuration file of x264 :

[ "$SYS" = "WINDOWS" -a "$gpl" = "no" -a "$thread" = "auto" ] && thread="win32"

libpthread="" if [ "$thread" = "auto" ]; then thread="no" case $SYS in BEOS) thread="beos" define HAVE_BEOSTHREAD ;; WINDOWS) if cc_check pthread.h -lpthread "pthread_create(0,0,0,0);" ; then thread="posix" libpthread="-lpthread" elif cc_check pthread.h -lpthreadGC2 "pthread_create(0,0,0,0);" ; then thread="posix" libpthread="-lpthreadGC2" elif cc_check pthread.h "-lpthreadGC2 -lwsock32 -DPTW32_STATIC_LIB" "pthread_create(0,0,0,0);" ; then thread="posix" libpthread="-lpthreadGC2 -lwsock32" define PTW32_STATIC_LIB elif cc_check pthread.h "-lpthreadGC2 -lws2_32 -DPTW32_STATIC_LIB" "pthread_create(0,0,0,0);" ; then thread="posix" libpthread="-lpthreadGC2 -lws2_32" define PTW32_STATIC_LIB else

default to native threading if pthread-win32 is unavailable

            thread="win32"
        fi
        ;;
    QNX)
        cc_check pthread.h -lc "pthread_create(0,0,0,0);" && thread="posix" && libpthread="-lc"
        ;;
    *)
        if cc_check pthread.h -lpthread "pthread_create(0,0,0,0);" ; then
           thread="posix"
           libpthread="-lpthread"
        else
            cc_check pthread.h "" "pthread_create(0,0,0,0);" && thread="posix" && libpthread=""
        fi
        ;;
esac

fi if [ "$thread" = "posix" ]; then LDFLAGS="$LDFLAGS $libpthread" define HAVE_POSIXTHREAD if [ "$SYS" = "LINUX" ] && cc_check sched.h "-D_GNU_SOURCE -Werror" "cpu_set_t p_aff; return CPU_COUNT(&p_aff);" ; then define HAVE_CPU_COUNT fi fi if [ "$thread" = "win32" ]; then

cygwin does not support win32 threads

if [ "$SYS" = "WINDOWS" ]; then
    define HAVE_WIN32THREAD
else
    thread="no"
fi

fi [ "$thread" != "no" ] && define HAVE_THREAD

Can something like this also be made ?

[qyot27]

No, because x264's posix threading support on Windows is: A) Provided by an external library or one provided by the toolchain (pthreads-w32 or winpthreads) B) Has nothing to do with std::thread and C++11, because x264 is written in plain C.

This is not the case for FFMS2, because it is written in C++, with (at the very least) the threading portion upgraded to use C++11 threading. This can't be glossed over with pthreads-w32, because the only way the headers for std::thread are made available to GCC is by enabling --enable-threads=posix when you build GCC itself. It won't install those headers if GCC uses win32 threads internally, and pthreads-w32 doesn't provide them or provide a way around them.

[qyot27]

Also, x264's configure trickery is thanks to the fact they use a hand-written tailored configure script, like FFmpeg does. FFMS2's master branch uses autotools, and while the c_plugin branch uses an x264-like configure script, that still doesn't change the fact that the problem is much deeper than providing case switching fallbacks in configure.

[tgoyne]

Currently std::thread::hardware_concurrency() is the only threading thing used so it should be trivial to provide a fallback if std::thread is unavailable, but that probably won't remain true forever.

[jpsdr]

Thanks for all your answers.