ffmpeg under windows is compiled on the mingw platform. I use msys2 and I need h264, so I first compiled the x264 static library in msys2. Note that this is a static library. The dynamic library has been linked, and the following problems will not occur , and then use the following configuration command in ffmpeg to generate Makefile.
./configure --toolchain=msvc --arch=x86_64 --disable-debug --enable-gpl --enable-libx264 --extra-cflags=-I/usr/local/x264/include --extra-ldflags= '-LIBPATH:/usr/local/x264/lib' --prefix=/home/ffmpeg_x264_static
Note that when compiling ffmpeg, --toolchain=msvc means compiling with Microsoft compiler.
As a result, configure reports an error, and the information is as follows:
Open ffbuild/config.log, and the following error is reported
The symbol __mingw_vsprintf could not be found. I was very curious. I searched for the place where __mingw_vsprintf was called in the x264 code. Obviously, I couldn’t find it directly. So I went to stdio.h in msys2 and searched for this symbol. I found it, as shown in the figure below. As shown
, in fact, the cross-platform open source code like x264, the outer layer calls sprintf, and then sprintf is implemented by the runtime library. Different runtime libraries have different internal functions. I have used clang to compile webrtc. Inside The runtime library prefix is another set, I forgot about it.
So if you want to pass ffmpeg configure, you need to find the implementation library of __mingw_vsprintf. Readers can also understand that you need to find the runtime library of mingw. For this reason, I wrote a special example and wrote a 1.c in mingw.
gcc -c 1.c generates object file 1.o.
Then call this mysprintf function with vs2017 as follows:
// mingwruntimetest.cpp : 此文件包含 "main" 函数。程序执行将在此处开始并结束。
//
#include <iostream>
extern "C" void mysprintf();
int main()
{
mysprintf();
std::cout << "Hello World!\n";
return 0;
}
Since the definition place of the symbol mysprintf is needed, the 1.o compiled in mingw needs to be linked in. The linker configuration is as follows:
Compile and report the following error:
At this time, the situation is the same as when configure reported an error in ffmpeg. Find the file libmingwex.a defined by the symbol __mingw_vsprintf, copy it to the project directory, and then configure the link, as shown below: Compile, and report the following error: The symbol
___chkstk_ms
failed Found it, so I found the static library file libgcc.a where this symbol is located again, and copied it to the project directory, and configured the project link as follows:
compile again, and the compilation passed.
Readers may have some doubts about how to know that the __mingw_vsprintf symbol is defined in libmingwex.a, and ___chkstk_ms is defined in libgcc.a. Readers can search for __mingw_vsprintf in the lib directory of msys2, and the files containing this symbol will be searched out.
Finally, let me explain: large-scale software like ffmpeg relies on a lot of plug-ins. If the plug-ins are compiled with static libraries, please keep these static libraries and the final ffmpeg compiled with the same compiler, so as not to need to run each compiler in the end. The time library is included, and you will find yourself guilty.
So the final solution is to compile the static library of x264 with vs2017. If x264 is a dynamic library, it can be compiled directly with mingw, but there will be an extra x264.dll in the final product.
Just imagine, if ffmpeg itself and the various plug-ins that ffmpeg depends on are compiled with static libraries, then under windows, compiling is actually a very laborious thing. I once saw a blogger who wrote ffmpeg compilation under windows, unexpectedly It was found that ffmpeg compiled 73, which is equivalent to writing at least 73 blogs for ffmpeg compilation.
ffmpeg compilation under linux is relatively simple