This reverts commit 67c72f08a4.
While the linker produced import libraries might work with MSVC in
simple test cases, they don't if e.g. linking to multiple GNU ld
produced import libraries at the same time. (They end up importing
functions from the wrong libraries.) The ones produced by dlltool
work fine though.
This issue was pointed out by Hendrik Leppkes.
Signed-off-by: Martin Storsjö <martin@martin.st>
Requires AMF headers for at least version 1.4.4.1.
Signed-off-by: Mikhail Mironov <mikhail.mironov@amd.com>
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
There is no longer any need for a list of them at runtime, because
decoders now carry the pointers to their associated hwaccels internally.
The file containing external declarations is now used to make the list
of hwaccels for configure.
The only purpose of dllexport (which is set while building the library
that exports the symbols) is to have the linker automatically
export such symbols into a DLL without using a def file - it doesn't
affect the generated code.
For both MSVC and mingw builds, this isn't essential since we override
what symbols to export via an autogenerated def file instead.
Update a comment in configure to refer to the right concept.
With lld, this avoids warnings about duplicate export directives,
when some symbols are requested to be exported both via dllexport
attributes and via the autogenerated def file.
This also reduces the number of lines of code marginally.
Signed-off-by: Martin Storsjö <martin@martin.st>
This avoids having to use either "dumpbin -headers" to find out
the current architecture, or pass $ARCH from configure to deduce it.
When configuring with --disable-asm, ARCH is equal to "c", which doesn't
give any indication of what symbol prefix is to be used.
Signed-off-by: Martin Storsjö <martin@martin.st>
- Move a variable closer to where it is used
- Add an explanatory comment
- Simplify a crosscompile check
- Minor SHFLAGS simplification
- Coalesce some threads tests
- Move generating config.fate to a more sensible place.
- Move printing warnings to a more appropriate place.
- Improve "generated by" comment in libavutil/avconfig.h.
- Drop pointless informative output about generating config files.
- Write a standard comment header to config.asm as well.
- Reuse sanitize_var_name() where appropriate
- Add some quotes to enabled()/disabled() to ease readability
- Fix logged names of some helper functions
- Filter LDFLAGS also in test_ldflags()
There shouldn't be any functional difference between the import
library created by dlltool and the one produced by the linker itself.
Keep installing it with both names though, for compatibility with users
that expect both to exist.
The dlltool step was added in ec10a9ab4; prior to that, a MSVC
compatible import library was generated using lib.exe. After that
commit, there was no functional difference between the two import
libraries (and since MSVC 2012, link.exe works just fine with the
GNU binutils generated one).
Signed-off-by: Martin Storsjö <martin@martin.st>
Support for this device has been removed in the Linux kernel since v2.6.37.
dv1394 has been superseded by libiec61883 which is functionally equivalent.
Signed-off-by: Josh de Kock <josh@itanimul.li>
Signed-off-by: Diego Biurrun <diego@biurrun.de>
The libavformat API is not suitable for exporting output devices as muxers.
Some practical problems are e.g. lack of timing/synchronization mechanisms
or interaction with output-specific features.
On X86 windows, asflags weren't actually ever used for anything,
since assembling used x86asflags instead, and that flags list
had -DPIC already.
This fixes building shared libraries with clang for arm/aarch64
windows. (This wasn't an issue when in msvc mode before, since
we don't try to enable pic at all there, since the msvc armasm
assembler fails on our pic constructs there.)
Signed-off-by: Martin Storsjö <martin@martin.st>
We skipped adding it to cflags for mingw/cygwin configurations
where the compiler either complains loudly or even errors out;
do the same for target_os=win32, for the case when building with
clang in msvc mode.
This wasn't needed for the actual msvc before, since msvc uses
msvc_common_flags to filter out this flag from cflags.
When building with clang in msvc mode, no such filter is used.
This fixes building shared libraries with clang in msvc mode.
Signed-off-by: Martin Storsjö <martin@martin.st>
