Building the ffmpeg Libs as static (.lib) files on Windows - windows

I've got the build environment set up: https://www.linkedin.com/pulse/building-ffmpeg-windows-without-fuss-moshe-david
From this I can successfully build ffmpeg.exe but I want to build libavcodec.lib etc statically for use with my project. I assume it's just a simple command line option for ./configure that I'm missng, but
--enable-static builds the exe and --enable-shared builds the dlls...
Any help on this would be much appreciated!
Best,
Peter

Turns out that the libraries (.a) files were being produced anyway and were in the respective folders. These work on windows of course, and can be copied out and linked in your project.

Related

Understanding roles of CMake, make and GCC

1. cmake is a command from CMake software: preparation for build automation system; make and make install are commands from Make software: build automation system.
2. From reading this post, what I understand is that:
a. This "cmake and make" stuffs actually use g++ / gcc in its implementation. cmake and make stuffs are basically just tools in using g++ / gcc. Is that correct?
b. gcc / g++ are the compiler that do the actual work.
c. So I can just use gcc / g++ directly without using the make and CMake things?
3. According to this stackoverflow answer: CMake takes a CMakeList.txt file, and outputs it to a platform-specific build format, e.g., a Makefile, Visual Studio, etc.
However when I came across this openCV installation :
mkdir release
cd release
cmake -D CMAKE_BUILD_TYPE=RELEASE -D CMAKE_INSTALL_PREFIX=/usr/local ..
It executes cmake command in a directory where there is no CMakeLists.txt file. Can you explain and elaborate on this?
4. The usual steps that I've seen are: cmake, make, sudo make install.
I read this stackoverflow post, what I understand:
(i) make is for building the project.
(ii) make install is to copy the binary / executables to the installed directories.
a. So when we make, where are the result / binary files / executables stored at?
b. If we only run make without make install, does it mean that the files are not generated?
c. I came across this openCV tutorial on using openCV with GCC and CMake. It uses:
cd <DisplayImage_directory>
cmake .
make
Why doesn't it do make install as well?
5. In summary:
CMake takes CMakeList.txt file (which is cross platform) to generate a Makefile (which is specific to a platform).
I can just write Makefile manually and skip the CMake step. but it is better to do with the CMake step because it is cross platform, otherwise I have to rewrite the Makefile again if I change platform.
Make takes Makefile (which is generated by CMake or written manually) as a guide to compile and build. Make basically uses gcc / g++ or other compiler in its work. Make itself is just a tool for the compiler.
Make install put the result / executables into the install path
CMake generates files for other build systems. These can be Makefiles, Ninja files or projects files for IDEs like Visual Studio or Eclipse. The build files contain calls to compilers like GCC, Clang, or cl.exe. If you have several compilers installed, you can choose one.
All three parts are independent. The compiler, the build system and CMake.
It is easier to understand when you have the history. People used their compiler. Over time they added so many flags, that it was cumbersome to type them every time. So they put the calls in a script. From that the build systems (Make, Ninja) evolved.
The people wanted to support multiple platforms, compilers, scenarios and so on and the build system files became hard to maintain and their use was error-prone. That's the reason people invented meta build system that creates the files for the actual build system. Examples are Autotools or CMake.
Yes
CMake does not use your compiler, make does not implement it, but it calls (uses) the compiler.
The CMakeLists.txt file should be in the parent directory of release. The last argument of the CMake call indicates the path where the CMakeLists.txt file is located.
Right, make generates the file in the build directory. In your example from 3. release is the build directory. You can find all the generated files and use them. Installing is optional, especially if you want to develop the software, you are not installing it.
Try writing Makefiles for a large project and you will see how much work it is. But yes, everything in 5 is right.

Build dynamic windows library (DLL) from libmcrypt with MinGW

I'm trying to build libmcrypt library to use it with my project. It happened so, that they do not provide any kind of assistance.
First I've faced a problem with -no-undefined flag for gcc which is not further supported. I've replaced -no-undefined with -Wl,-no-undefined in makefiles and it does the trick.
But anyway I'am having problems. Lib is builded in .a files. I can see them in my C:\MinGW\msys\1.0\local\lib folder (it is analogue for /usr/local/lib folder in MinGW). But I need .dll library, not static .a .
So: what else must I change in makefiles to make MinGW build dll with header and debug info for it?

Link ffmpeg lib statically in Visual Studio

I'm trying to use ffmpeg in my C++ project on VS2010, and the ffmpeg dev version provides the lib of .h files. I linked these .libs in my projects and the corresponding .dlls are required when running the .exe file. But I want to link the ffmpeg lib statically and running without .dlls.
I tryed to compile the ffmpeg source code on windows with Mingw, only resulting on some .a archive files. How to get ffmpeg static .lib files? And it's a 64bit program so 64bit static lib is required.
In your output directory, you have some *.def files. You can use these files to get your *.lib files. The syntax is:
lib /def:avcodec-54.def /out:avcodec-54.lib
Use the lib.exe of your VS version. Mine is located in C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\bin. Check the command line options (it way be useful to add /machine:i386).
Another way to do this: instead of using windows's cmd directly to start msys/mingw, first start VS command prompt (you can start it from Start menu). It will set some environment variables. From here, compile FFmpeg with msys/mingw: FFmpeg build will autodetect that VS is present, thus will auto-perform the libcall.
Edit: Sorry, I skipped the "static" part of the question. Here are some tips for a static build (note that I've never build a static FFmpeg used inside visual studio, so maybe it will not work).
First, of course, FFmpeg must be built with the static options: just to be sure, I use these options, so I have no .def of shared files:
./configure --enable-static --disable-shared [other options]
In order to have statically files, you may directly use the .a files (again: I never thried this). Check this question.
If it does not work, you can try the visual studio toochain instead of gcc. But be careful: last time I tried this (but a shared dll), FFmpeg decoding was slower when build from msvc than gcc's output. Check this page for detailed build instructions.

code::blocks linking doesn't work for lib files

I just had a fresh new version of Code::Blocks(12.11) and tried to make a glut example project, but the generated code has some linking issues.
The minGW settings are is set to the correct values, since I successfully linked ad compiled a glfw project from *.a files. My problem is the linker just can't handle .lib files for some reason. I always get undefined reference errors, despite of the linking of the correct libraries.
I just don't know what to do/link...
How can I link *.lib files in the new Code::blocks?
IF I cannot, are there any glut binaries in the format of *.a files, or should I build it myself?
Finally I found this link, used this package, and did a clean build(rebuild) of the project, instead of Build. Works like a charm!

crtbegin_so.o missing for android toolchain (custom build)

I have compiled gdc together with gcc using the android build-gcc.sh script, and have included a new stub in build/core/definitions.mk to deal with D language files as a part of the build process. I know things are compiling OK at this point, but my problem is linking:
When I build a project, I get this error:
ld: crtbegin_so.o: No such file: No such file or directory
This is true for regular c-only projects as well. Now I ran a quick find in my build directory, and found that the file (crtbegin_so.o) does exist within the sysroot I specified when I compiled gcc (or rather, when build-gcc.sh built it).
What are some things I could look for to find a solution to this problem?
Would copying the files locally and linking directly to them be a decent solution in the
interim?
Why would ld (or collect2) be trying to include these for a gdc (D Language) linkage?
The issue arises on NDK r7c for linux as well.
I found that the toolchain ignores the platform location ($NDK_ROOT/platforms/android-8/arch-arm/usr/lib/) and searches for it in the toolchain path, which is incorrect.
However, as the toolchain also searches for the file in the current directory, one solution is to symlink the correct platform crtbegin_so.o and crtend_so.o into the source directory:
cd src && ln -s NDK_ROOT/platforms/android-8/arch-arm/usr/lib/crtbegin_so.a
cd src && ln -s NDK_ROOT/platforms/android-8/arch-arm/usr/lib/crtend_so.a
Thus your second point should work out (where you can do a symlink, instead of a copy)
NOTE 1:This assumes that the code is being compiled for API8 (Android 2.2) using the NDK. Please alter the path to the correct path as per your requirement.
NOTE 2:Configure flags used:
./configure \
--host=arm-linux-androideabi \
CC=arm-linux-androideabi-gcc \
CPPFLAGS="-I$NDK_ROOT/platforms/android-8/arch-arm/usr/include/" \
CFLAGS="-nostdlib" \
LDFLAGS="-Wl,-rpath-link=$NDK_ROOT/platforms/android-8/arch-arm/usr/lib/ -L$NDK_ROOT/platforms/android-8/arch-arm/usr/lib/" \
LIBS="-lc"
I have found that adding --sysroot=$(SYSROOT) to the compiler options fixes the error:
cannot open crtbegin_so.o: No such file or directory
from my makefile...
CC= $(CROSS_COMPILE)gcc -fvisibility-hidded $(INC) $(LIB) -shared
Note: this assumes that the setenv-android.sh has been run to setup the environment
$. ./setenv-android.sh
In my case quotes were missing from sysroot path.
When I changed
--sysroot=${ANDROID_NDK}\platforms\android-17\arch-arm
to
--sysroot="${ANDROID_NDK}\platforms\android-17\arch-arm"
the project was compiled and linked successfully.
I faced with the same issue in two separate cases:
during building boost for android
during using android-cmake project.
Once I have switched to standalone toolchain issue gone, here is example of command which prepare standalone toolchain
$NDK_ROOT/build/tools/make-standalone-toolchain.sh --platform=android-9 --install-dir=android-toolchain --ndk-dir=$NDK_ROOT --system=darwin-x86_64 --toolchain=arm-linux-androideabi-4.9
Boost specific
for boost you need specify --sysroot several times in your jam
<compileflags>--sysroot=$NDK_ROOT/platforms/android-9/arch-arm
<linkflags>--sysroot=$NDK_ROOT/platforms/android-9/arch-arm

Resources