Initial support for the ICL compiler on windows. Requires a new
c99wrap with ICL support (1.0.2+).
Currently not much different speed wise compared to msvc. In the
future with a few changes it can be made to support the inline asm.
This would be the primary reason for using it.
Passed all fate tests, versions tested:
13.1.1.171 (2013 Update 3) x86 and x64
12.1.5.344 (2011 Update 11) x86 and x64
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
Change the check_exec_crash test to use a function pointer instead of
simply calling the function. The EBP availability test will crash when
compiled with ICL likely due to compiler optimization shenanigans.
Originally the check_exec_crash code was moved out of main to fix a
problem with gcc's treatment of non-leaf main on x86_32. Libav already
moved the code out of main but the addition of the function pointer will
prevent any inlining which fixes the remaining problem.
A function pointer is used since it is compiler agnostic (as opposed to
say __attribute__ ((noinline)) which would only work with gcc compatible
compilers).
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
MSVC 2010 (or more precisely, Windows SDK 7.0 which comes with MSVC
2010) sets _WIN32_WINNT to the constant for Windows 7 if nothing is
set. This could lead to the libav configure script detecting and
using functions only present in Windows 7 or newer, which in most
cases isn't desired. If the caller explicitly wants this, the caller
can add the _WIN32_WINNT define via --extra-cflags, setting the desired
version.
Signed-off-by: Martin Storsjö <martin@martin.st>
With the parameter --toolchain valgrind-massif, the configure
script sets reasonable defaults that can be overridden as explained
in the documentation.
This makes it consistent with the msvc builds which automatically set
the DEP and ASLR flags by default. There really is no good reason why
they shouldn't be set.
The fact that binutils does not set them on by default boggles the mind.
Signed-off-by: Martin Storsjö <martin@martin.st>
If this is explicitly disabled for win32/mingw, it should also
be disabled for cygwin, for consistency and for the same reasons
as for win32/mingw.
Signed-off-by: Martin Storsjö <martin@martin.st>
These platforms do not have any notion of PIC. On some compilers,
enabling pic produces a number of warnings.
This avoids trying to produce PIC loads in the ARM assembly - there
are no relocation types in PE/COFF that correspond to
BFD_RELOC_32_PCREL (R_ARM_REL32 in ELF).
As a side-effect, this avoids enabling PIC on mingw64, getting rid
of the warnings about PIC not having any effect on that platform.
Signed-off-by: Martin Storsjö <martin@martin.st>
This allows it to be overridden, either by the user on the command
line, or by other sections of the configure script.
Signed-off-by: Martin Storsjö <martin@martin.st>
When targeting the "windows store application" (metro) API subset
(or the windows phone API subset), the getenv function isn't
available. If it is unavailable, just define getenv to NULL.
The check uses check_func_headers, since the function actually
might exist in the libraries, but is hidden in the headers.
The fallback is in config.h since msvc can't do -D defines with
parameters on the command line, and it's used both within the
libraries and the frontend applications (so a libavutil internal
header wouldn't be enough).
Signed-off-by: Martin Storsjö <martin@martin.st>
With the parameter --valgrind-memcheck, the configure script sets
reasonable defaults that can be overridden as explained in the
documentation.
The idea of using set_defaults is from Luca Barbato.
If building libav with -MD in the cflags (for making the MSVC compiler
generate code for using a dynamically linked libc), the system headers
that declare strtod, snprintf and vsnprintf declare the functions as
imported from a DLL. To hook up wrappers of our own for these functions,
the function names are defined to avpriv_*, so that the calling code
within libav calls the wrappers instead. Since these functions
are declared to be imported from DLLs, the calling code expects to
load them from DLL import function pointers (creating references to
_imp__avpriv_strtod instead of directly to avpriv_strtod). If the
libav libraries are not built as DLLs, no such function pointers (as
the calling code expects) are created.
The linker can fix this up automatically in some cases (producing
warnings LNK4217 and LNK4049), if the object files are already
included. By telling the linker to try to include those symbols
(without the _imp prefix as the calling code ends up using),
we get the object files included, so that the linker can do the
automatic fixup. This is done via config.h, so that all (or at least
most) of the object files in our libraries force including the compat
files, to make sure they are included regardless of what files from our
static libraries actually are included.
Signed-off-by: Martin Storsjö <martin@martin.st>
This avoids cases where configure tries to weakly enable an item
which actually is disabled, ending up still enabling dependencies
of the item which itself is only enabled weakly.
More concretely, the h264 decoder suggests error resilience, which
is then enabled weakly (unless manually disabled). Previously,
dsputil, which is a dependency of error resilience, was enabled
even if error resilience wasn't enabled in the end.
Signed-off-by: Martin Storsjö <martin@martin.st>
The variable name 'var' is commonly used to iterate through arguments
in other functions. When the pushvar function internally uses the
variable 'var', it makes pushing/popping the variable 'var' not
work as intended.
Signed-off-by: Martin Storsjö <martin@martin.st>
vidstabdetect and vidstabtransform common functions for interfacing
vid.stab are in libavfilter/vidstabutils.c
Signed-off-by: Georg Martius <martius@mis.mpg.de>
Alex Smith
Laurent
Carl Eugen Hoyos
Martin Storsjö
Clément Bœsch
Michael Niedermayer
Lukasz Marek
Luca Barbato
Kostya Shishkov
Stefano Sabatini
Diego Biurrun
Anton Khirnov
Reinhard Tartler
highgod0401
Georg Martius
Ronald S. Bultje