mirror of
https://git.ffmpeg.org/ffmpeg.git
synced 2026-10-24 02:09:03 +03:00
Describe the current UCRT64, CLANG64 and CLANGARM64 environments, point to the per-environment launchers, use pacboy so the package commands work in every environment, and update the stale MSYS2 and MinGW-w64 URLs. Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
285 lines
9.0 KiB
Plaintext
285 lines
9.0 KiB
Plaintext
\input texinfo @c -*- texinfo -*-
|
|
@documentencoding UTF-8
|
|
|
|
@settitle Platform Specific Information
|
|
@titlepage
|
|
@center @titlefont{Platform Specific Information}
|
|
@end titlepage
|
|
|
|
@top
|
|
|
|
@contents
|
|
|
|
@chapter Unix-like
|
|
|
|
@section Advanced linking configuration
|
|
|
|
If you compiled FFmpeg libraries statically and you want to use them to
|
|
build your own shared library, you may need to force PIC support (with
|
|
@code{--enable-pic} during FFmpeg configure) and add the following option
|
|
to your project LDFLAGS:
|
|
|
|
@example
|
|
-Wl,-Bsymbolic
|
|
@end example
|
|
|
|
If your target platform requires position independent binaries, you should
|
|
pass the correct linking flag (e.g. @code{-pie}) to @code{--extra-ldexeflags}.
|
|
|
|
@section BSD
|
|
|
|
BSD make will not build FFmpeg, you need to install and use GNU Make
|
|
(@command{gmake}).
|
|
|
|
@section (Open)Solaris
|
|
|
|
GNU Make is required to build FFmpeg, so you have to invoke (@command{gmake}),
|
|
standard Solaris Make will not work.
|
|
|
|
@anchor{Darwin}
|
|
@section Darwin (Mac OS X, iPhone)
|
|
|
|
The toolchain provided with Xcode is sufficient to build the basic
|
|
unaccelerated code.
|
|
|
|
macOS on x86 requires @command{nasm} to build most of the
|
|
optimized assembly functions.
|
|
@uref{https://wiki.gentoo.org/wiki/Project:Prefix, Gentoo Prefix},
|
|
@uref{https://brew.sh/, Homebrew}
|
|
or @uref{https://www.macports.org, MacPorts} can easily provide it.
|
|
|
|
|
|
@chapter DOS
|
|
|
|
Using a cross-compiler is preferred for various reasons.
|
|
@url{http://www.delorie.com/howto/djgpp/linux-x-djgpp.html}
|
|
|
|
|
|
@chapter OS/2
|
|
|
|
For information about compiling FFmpeg on OS/2 see
|
|
@url{http://www.edm2.com/index.php/FFmpeg}.
|
|
|
|
|
|
@chapter Windows
|
|
|
|
@section Native Windows compilation using MinGW or MinGW-w64
|
|
|
|
FFmpeg can be built to run natively on Windows using the MinGW-w64
|
|
toolchain. Install the latest versions of MSYS2 and MinGW-w64 from
|
|
@url{https://www.msys2.org/} and/or @url{https://www.mingw-w64.org/}.
|
|
You can find detailed installation instructions in the download section and
|
|
the FAQ.
|
|
|
|
Notes:
|
|
|
|
@itemize
|
|
|
|
@item Building for the MSYS environment is discouraged, use one of the
|
|
MinGW-w64 environments provided by MSYS2 instead. UCRT64 provides a GCC
|
|
based toolchain, CLANG64 a LLVM based one and CLANGARM64 targets Windows
|
|
on ARM64.
|
|
|
|
@item Building using MSYS2 can be sped up by disabling implicit rules in the
|
|
Makefile by calling @code{make -r} instead of plain @code{make}. This
|
|
speed up is close to non-existent for normal one-off builds and is only
|
|
noticeable when running make for a second time (for example during
|
|
@code{make install}).
|
|
|
|
@item In order to compile FFplay, you must have the MinGW development library
|
|
of @uref{http://www.libsdl.org/, SDL} and @code{pkg-config} installed.
|
|
|
|
@item By using @code{./configure --enable-shared} when configuring FFmpeg,
|
|
you can build the FFmpeg libraries (e.g. libavutil, libavcodec,
|
|
libavformat) as DLLs.
|
|
|
|
@end itemize
|
|
|
|
@subsection Native Windows compilation using MSYS2
|
|
|
|
The MSYS2 MinGW-w64 environments provide ready to use toolchains and
|
|
dependencies through @command{pacman}.
|
|
|
|
Launch the shell of the environment you want to build in using its
|
|
launcher, for example @file{ucrt64.exe} or the corresponding start menu
|
|
shortcut for UCRT64. Then install the toolchain and the FFmpeg
|
|
dependencies. The @command{pacboy} wrapper from the @code{pactoys}
|
|
package fills in the package name prefix of the current environment, so
|
|
the same command works in every environment.
|
|
|
|
@example
|
|
# normal msys2 packages
|
|
pacman -S make pkgconf diffutils pactoys
|
|
|
|
# mingw-w64 packages and toolchains for the current environment
|
|
pacboy -S cc nasm SDL2
|
|
@end example
|
|
|
|
@section Microsoft Visual C++ or Intel C++ Compiler for Windows
|
|
|
|
FFmpeg can be built with MSVC 2019 16.8 or later, the first version able to
|
|
compile C11.
|
|
|
|
You will need the following prerequisites:
|
|
|
|
@itemize
|
|
@item @uref{https://www.msys2.org/, MSYS2}
|
|
@item @uref{https://www.nasm.us/, NASM}
|
|
(Also available via MSYS2's package manager.)
|
|
@end itemize
|
|
|
|
To set up a proper environment in MSYS2, you need to run
|
|
@code{msys2_shell.cmd -use-full-path} from the Visual Studio or Intel Compiler
|
|
command prompt.
|
|
|
|
Place @code{nasm.exe} somewhere in your @code{PATH}.
|
|
|
|
Next, make sure any other headers and libs you want to use, such as zlib, are
|
|
located in a spot that the compiler can see. Do so by modifying the @code{LIB}
|
|
and @code{INCLUDE} environment variables to include the @strong{Windows-style}
|
|
paths to these directories. Alternatively, you can try to use the
|
|
@code{--extra-cflags}/@code{--extra-ldflags} configure options.
|
|
|
|
Finally, run:
|
|
|
|
@example
|
|
For MSVC:
|
|
./configure --toolchain=msvc
|
|
|
|
For ICL:
|
|
./configure --toolchain=icl
|
|
|
|
make
|
|
make install
|
|
@end example
|
|
|
|
If you wish to compile shared libraries, add @code{--enable-shared} to your
|
|
configure options. Note that due to the way MSVC and ICL handle DLL imports and
|
|
exports, you cannot compile static and shared libraries at the same time, and
|
|
enabling shared libraries will automatically disable the static ones.
|
|
|
|
Notes:
|
|
|
|
@itemize
|
|
|
|
@item If you wish to build with zlib support, you will have to grab a compatible
|
|
zlib binary from somewhere, with an MSVC import lib, or if you wish to link
|
|
statically, you can follow the instructions below to build a compatible
|
|
@code{zlib.lib} with MSVC. Regardless of which method you use, you must still
|
|
follow step 3, or compilation will fail.
|
|
@enumerate
|
|
@item Grab the @uref{http://zlib.net/, zlib sources}.
|
|
@item Edit @code{win32/Makefile.msc} so that it uses -MT instead of -MD, since
|
|
this is how FFmpeg is built as well.
|
|
@item Edit @code{zconf.h} and remove its inclusion of @code{unistd.h}. This gets
|
|
erroneously included when building FFmpeg.
|
|
@item Run @code{nmake -f win32/Makefile.msc}.
|
|
@item Move @code{zlib.lib}, @code{zconf.h}, and @code{zlib.h} to somewhere MSVC
|
|
can see.
|
|
@end enumerate
|
|
|
|
@end itemize
|
|
|
|
@subsection Linking to FFmpeg with Microsoft Visual C++
|
|
|
|
If you plan to link with MSVC-built static libraries, you will need
|
|
to make sure you have @code{Runtime Library} set to
|
|
@code{Multi-threaded (/MT)} in your project's settings.
|
|
|
|
If you plan on using import libraries created by dlltool, you must
|
|
set @code{References} to @code{No (/OPT:NOREF)} under the linker optimization
|
|
settings, otherwise the resulting binaries will fail during runtime.
|
|
This is not required when using import libraries generated by @code{lib.exe}.
|
|
This issue is reported upstream at
|
|
@url{http://sourceware.org/bugzilla/show_bug.cgi?id=12633}.
|
|
|
|
To create import libraries that work with the @code{/OPT:REF} option
|
|
(which is enabled by default in Release mode), follow these steps:
|
|
|
|
@enumerate
|
|
|
|
@item Open the @emph{Visual Studio Command Prompt}.
|
|
|
|
Alternatively, in a normal command line prompt, call @file{vcvarsall.bat}
|
|
which sets up the environment variables for the Visual C++ tools.
|
|
|
|
@item Enter the @file{bin} directory where the created LIB and DLL files
|
|
are stored.
|
|
|
|
@item Generate new import libraries with @command{lib.exe}:
|
|
|
|
@example
|
|
lib /machine:i386 /def:..\lib\foo-version.def /out:foo.lib
|
|
@end example
|
|
|
|
Replace @code{foo-version} and @code{foo} with the respective library names.
|
|
|
|
@end enumerate
|
|
|
|
@anchor{Cross compilation for Windows with Linux}
|
|
@section Cross compilation for Windows with Linux
|
|
|
|
You must use the MinGW-w64 cross compilation tools, which most Linux
|
|
distributions provide as packages.
|
|
|
|
Then configure FFmpeg with the following options:
|
|
@example
|
|
./configure --arch=x86_64 --target-os=mingw32 --cross-prefix=x86_64-w64-mingw32-
|
|
@end example
|
|
(you can change the cross-prefix according to the prefix chosen for the
|
|
MinGW-w64 tools).
|
|
|
|
Then you can easily test FFmpeg with @uref{https://www.winehq.org/, Wine}.
|
|
|
|
@section Compilation under Cygwin
|
|
|
|
Install your Cygwin with all the "Base" packages, plus the
|
|
following "Devel" ones:
|
|
@example
|
|
binutils, gcc-core, make, git, texinfo
|
|
@end example
|
|
|
|
In order to run FATE you will also need the following "Utils" packages:
|
|
@example
|
|
diffutils
|
|
@end example
|
|
|
|
If you want to build FFmpeg with additional libraries, download Cygwin
|
|
"Devel" packages for Ogg and Vorbis from any Cygwin packages repository:
|
|
@example
|
|
libogg-devel, libvorbis-devel
|
|
@end example
|
|
|
|
@section Crosscompilation for Windows under Cygwin
|
|
|
|
With Cygwin you can create Windows binaries that do not need the cygwin1.dll.
|
|
|
|
Just install your Cygwin as explained before, plus the MinGW-w64 cross
|
|
toolchain "Devel" packages:
|
|
@example
|
|
mingw64-x86_64-gcc-core, mingw64-x86_64-binutils
|
|
@end example
|
|
|
|
and configure with:
|
|
@example
|
|
./configure --arch=x86_64 --target-os=mingw32 --cross-prefix=x86_64-w64-mingw32-
|
|
@end example
|
|
|
|
@section ARM64EC
|
|
|
|
FFmpeg does not intend to support the Windows ARM64EC build configuration;
|
|
patches for changing the individual libraries for the purposes of ARM64EC will
|
|
not be accepted.
|
|
|
|
It may still be possible to build FFmpeg in this build configuration;
|
|
such a build may seem to work to some extent. Such a build may have some
|
|
amounts of ABI inconsistencies though - which we are not willing to fix.
|
|
|
|
(Changing aarch64 assembly code to strictly support ARM64EC would require
|
|
ifdeffing/changing essentially all such assembly code, and would be a
|
|
huge maintenance burden. Additionally, changing the library ABI
|
|
surfaces to fix ABI inconsistencies could require extensive and intrusive
|
|
changes.)
|
|
|
|
@bye
|