GitLab

AC_MSG_FAILURE is solely meant for configure check unexpected failure,
not for "normal" errors whereby a check detects a missing dependency.

It made things more complicated for MIT-SHM.

An issue regrading %zu vasprintf NOT being recognized
by mingw runtime's 3.14 is fixed with an upgrade to 3.15
So make this the least required standart.
Note that this issue lead to a vlc early crash on windows
and is generally toxic on cases where %s is following a
misinterpreted %zu
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

Signed-off-by: Rémi Denis-Courmont <remi@remlab.net>

Signed-off-by: Rémi Denis-Courmont <remi@remlab.net>

First step of fixing linking errors against libx264

Check for broken ld on Darwin 9 only

*printf as per MSVCRT is not c99 compliant.  mingw32 provides a set of
replacement functions, but these are buggy in old versions.

Defining __USE_MINGW_ANSI_STDIO causes mingw's stdio to provide a
set of wrappers that use the mingw32 version that gets statically
linked.

Attention needs to be given to contrib too, it is possible for contrib
to expect a c99 *printf and later die.  This patch modifies the conrtib
bootstrap to define the above in CPPFLAGS, however, not all builds
honour CPPFLAGS.

This can be validated by looking for the import from msvcrt:

  $ find vlc-w32/vlc-1.0.0-pre1/ -name '*.dll' -print -exec sh -c \
     'i586-mingw32msvc-nm {} | grep __imp__.*printf' ';'

If all is good, this shouldn't find anything.

This patch *will* break WinCE support.  However, it is semibroken
anyway; better to force it to be fixed completely.
Signed-off-by: David Flynn <davidf@rd.bbc.co.uk>
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

I am fed up with all the blame we got for this for over a year.

Signed-off-by: David Flynn <davidf@rd.bbc.co.uk>
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

On my linux x86_64 system, when trying to statically link the x264
module against libx264, I get the following error:

/usr/bin/ld: /usr/local/lib/libx264.a(cabac-a.o): relocation
R_X86_64_PC32 against symbol `x264_cabac_range_lps' can not be used when
making a shared object; recompile with -fPIC
/usr/bin/ld: final link failed: Bad value

Even though libx264 was compiled as PIC. Dynamically linking against the
shared library, built during the same process, works well.

The x264 folks said that VLC needed to use the -Bsymbolic flag to allow
conversation of a static PIC library into a shared library, so that's
what I did, and it works for me.
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

If you build your contrib out of tree (somehow), then a way
is needed to say where it is:

 configure CONTRIB_DIR=wherever
Signed-off-by: David Flynn <davidf@rd.bbc.co.uk>
Signed-off-by: Christophe Mutricy <xtophe@videolan.org>

Thread initialization has changed in 2.7, such that VLC and Qt4 cannot
both use libxml2. While this maximum version requirement is bound to
frustrate Linux/BSD users, we cannot fix this within VLC. Falling back
to xtag is not quite as bad as crashing.

We need libxml version 2.5 for text reader.
pkg-config is present since version 2.3 at least (over 8 years ago).