When linking the main tools, the object files to link are set up
via the variable OBJS-<name>, but for the tools, we've only
used the target's list of dependencies.
In most cases, this has been fine, but it has caused specifying
the libraries to link in a duplicate fashion; the linking command
has looked like this:
$CC -Llibavutil ... tools/tool.o libavutil/libavutil.a -lavutil
Normally, the libraries to link are handled with "-Llibavutil -lavutil";
when linking the main fftools, this is how they are linked.
In the case of the binaries under the "tools" directory (within the
make variable TOOLS), we've passed the full set of dependencies
to the linker, via $^, which does contain the names of the
dependency libraries as well.
When libraries are built as regular static libraries, or shared
unix libraries, this has all worked fine. When libraries are
built as DLLs for Windows, though, the norm is not to pass the
actual DLL to the linker, but an import library.
Mingw tools generally can handle linking directly against a DLL
as well, but MSVC tools don't support that, and error out with
a very cryptic error message:
libavdevice\avdevice.dll : fatal error LNK1107: invalid or corrupt file: cannot read at 0x2D8
By omitting these parts of the dependencies, linking of these tool
executables succeed in MSVC builds with shared libraries enabled.
Signed-off-by: Martin Storsjö <martin@martin.st>
Adding a new AVHWAccel also adds a new CONFIG variable for it
and said config variables are typically used to calculate the
size of stack arrays. In such a context, an undefined CONFIG
variable does not evaluate to zero; instead it leads to
a compilation failure. Therefore treat this file like the other
files containing lists of configurable components and prompt
for reconfiguration if it is modified.
(E.g. a44fba0b5b led to compilation
failures for me.)
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
On macOS, code-signing information for executables (including those signed
automatically by the linker) is cached by the system on a per-inode basis.
The cp(1) tool will truncate and overwrite an existing file if present,
so we need to delete it first to avoid strange crashes.
See https://developer.apple.com/documentation/security/updating_mac_software
This avoids having to rebuild big files every time FFMPEG_VERSION
changes (which it does with every commit).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
In case of shared builds, some object files containing tables
are currently duplicated into other libraries: log2_tab.c,
golomb.c, reverse.c. The check for whether this is duplicated
is simply whether CONFIG_SHARED is true. Yet this is crude:
E.g. libavdevice includes reverse.c for shared builds, but only
needs it for the decklink input device, which given that decklink
is not enabled by default will be unused in most libavdevice.so.
This commit changes this by making it more explicit about what
to duplicate from other libraries. To do this, two new Makefile
variables were added: SHLIBOBJS and STLIBOBJS. SHLIBOBJS contains
the objects that are duplicated from other libraries in case of
shared builds; STLIBOBJS contains stuff that a library has to
provide for other libraries in case of static builds. These new
variables provide a way to enable/disable with a finer granularity
than just whether shared builds are enabled or not. E.g. lavd's
Makefile now contains: SHLIBOBJS-$(CONFIG_DECKLINK_INDEV) += reverse.o
Another example is provided by the golomb tables. These are provided
by lavc for static builds, even if one uses a build configuration
that makes only lavf use them. Therefore lavc's Makefile contains
STLIBOBJS-$(CONFIG_MXF_MUXER) += golomb.o, whereas lavf's Makefile
has a corresponding SHLIBOBJS-$(CONFIG_MXF_MUXER) += golomb_tab.o.
E.g. in case the MXF muxer is the only component needing these tables
only libavformat.so will contain them for shared builds; currently
libavcodec.so does so, too.
(There is currently a CONFIG_EXTRA group for golomb. But actually
one would need two groups (golomb_avcodec and golomb_avformat) in
order to know when and where to include these tables. Therefore
this commit uses a Makefile-based approach for this and stops
using these groups for the users in libavformat.)
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
LSX and LASX is loongarch SIMD extention.
They are enabled by default if compiler support it, and can be disabled
with '--disable-lsx' '--disable-lasx'.
Change-Id: Ie2608ea61dbd9b7fffadbf0ec2348bad6c124476
Reviewed-by: Shiyou Yin <yinshiyou-hf@loongson.cn>
Reviewed-by: guxiwei <guxiwei-hf@loongson.cn>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Deprecated in c29038f304.
The resample filter based upon this library has been removed as well.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Signed-off-by: James Almer <jamrial@gmail.com>
And add it to the CONFIGURABLE_COMPONENTS list in Makefile. This way, changes
to the new file will be tracked and the usual warning to suggest re-running
configure will be shown.
Reviewed-by: Rostislav Pehlivanov <atomnuker@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
This reverts commit 0fd475704e.
Revert "lavd: fix iterating of input and output devices"
This reverts commit ce1d77a5e7.
Signed-off-by: Josh de Kock <josh@itanimul.li>
Split it off from install-data.
Among other things, this prevents spamming triplicate log lines during install.
Reviewed-by: Clément Bœsch <u@pkh.me>
Signed-off-by: James Almer <jamrial@gmail.com>
This also adds support to avconv (which is trivial due to the new
hwaccel API being generic enough).
The new decoder setup code in dxva2.c is significantly based on work by
Steve Lhomme <robux4@gmail.com>, but with heavy changes/rewrites.
Merges Libav commit f9e7a2f95a.
Also adds untested VP9 support.
The check for DXVA2 COBJs is removed. Just update your MinGW to
something newer than a 5 year old release.
Signed-off-by: Diego Biurrun <diego@biurrun.de>
It's not used by anything, has dubious usefulness, the reasons for which
it was introduced are no longer valid, and only serves to add complexity
to the build system.
Signed-off-by: James Almer <jamrial@gmail.com>