configure: work around bug in ash shell

The ash 'test' builtin misbehaves if the first operand of a binary
operator looks like a unary operator.

Signed-off-by: Mans Rullgard <mans@mansr.com>
configure: recognise Minix as OS

No special setup is required for Minix.

Signed-off-by: Mans Rullgard <mans@mansr.com>
configure: tms470: add mapping for -mfpu=vfpv3-d16 flag

Signed-off-by: Mans Rullgard <mans@mansr.com>
configure: improve tms470 compiler usage with glibc

Apply flags to work around glibc quirks only if glibc is detected,
and add a few more such flags.

Do not mess with as/ld settings in probe_cc.  This is not the
proper place.

Signed-off-by: Mans Rullgard <mans@mansr.com>
build: tms470: work around glibc math.h problems

The glibc definitions of INFINITY and NAN do not work with the
tms470 compiler, nor do our usual fallbacks.

Signed-off-by: Mans Rullgard <mans@mansr.com>
avutil: Rename ff_set_systematic_pal2() ---> avpriv_set_systematic_pal2()

Functions used across libraries should have avpriv_ and not ff_ prefixes.
avutil: Do not make ff_ symbols globally visible.
lavc: update documentation for AVFrame.extended_data
shorten: use planar sample format
wmadec: use float planar sample format output
wmalossless: output in planar sample format
wmapro: use planar sample format
Revert "configure: x86: improve ebp availability check"

This makes cabac-test work on 32-bit mingw, to ease testing/comparison
between MSVC and mingw.

This reverts commit 692dd8ed2617f390ff53b1152a21170e886be726.
configure: Split out msvc as a separate target OS

The name mingw32 as target OS is both misleading, and very little
of the target OS specific settings actually match.

Since the target OS default is set based on uname, the default
(which on MSYS is set to mingw) is overridden by --toolchain=msvc.
Add support for building shared libraries with MSVC

This requires the makedef perl script by Derek, from the c89-to-c99
repo. That scripts produces a .def file, listing the symbols to be
exported, based on the gcc version scripts and the built object files.

To properly load non-function symbols from DLL files, the data
symbol declarations need to have the attribute __declspec(dllimport)
when building the calling code. (On mingw, the linker can fix this
up automatically, which is why it has not been an issue so far.)

The __declspec(dllimport) attribute is added via a macro. Since
it has to be present when building code that refers to these symbols,
but not be present while building the library that exports the symbols
themselves, the Makefile is modified to add a define like
COMPILING_<libname> while building each library. This is used in the
definition of the <lib>_exportdata macro - on non-MSVC compilers, it is
empty. On MSVC, it is __declspec(dllimport) for declarations in other
libraries than the object file currently compiled.

This also implies that code that is built to link to a certain
library as a DLL can't link to the same library as a static library.
Therefore, we only allow building either static or shared but not
both at the same time. (That is, static libraries as such can be,
and actually are, built - this is used for linking the test tools to
internal symbols in the libraries - but e.g. libavformat object files
built to link to libavcodec as a DLL cannot link statically to
libavcodec.)

Also, linking to DLLs is slightly different from linking to shared
libraries on other platforms. DLLs use a thing called import
libraries, which is basically a stub library allowing the linker
to know which symbols exist in the DLL and what name the DLL will
have at runtime.

In mingw/gcc, the import library is usually named libfoo.dll.a,
which goes next to a static library named libfoo.a. This allows gcc
to pick the dynamic one, if available, from the normal -lfoo switches,
just as it does for libfoo.a vs libfoo.so on Unix. On MSVC however,
you need to literally specify the name of the import library instead of
the static library.