The documentation of libav says -Bsymbolic may be needed when building a
shared library which links statically to libav.
Fixes linking error on FreeBSD:
gst-libav/gst-libs/ext/.libs/libavcodec.a(simple_idct10.o):
relocation R_X86_64_PC32 against `ff_pw_1023' can not be used when making a
shared object; recompile with -fPIC
/usr/bin/ld: final link failed: Bad value
https://bugzilla.gnome.org/show_bug.cgi?id=791783
Autotools automatically appends user CPPFLAGS after target
CPPFLAGS. Also, it puts all CPPFLAGS before CFLAGS in final
generated gcc compile command. The internal ffmpeg include
paths need to come before any other external include paths
to ensure we don't accidentally pickup external ffmpeg
headers first (i.e. from user CPPFLAGS include paths). Thus,
move the internal LIBAV include paths to LIBAV_CPPFLAGS so
that they come before any user defined CPPFLAGS.
This allows ffmpeg and gst-ffmpeg to coexist on users system.
https://bugzilla.gnome.org/show_bug.cgi?id=789379
While all this information is in the .la files, libtool seems to get
confused with ordering in presence of static system libraries. This could
cause missing symbol error at link time. Adding these depenencies explicitly
workaround the issue.
Add gas-preprocessor.pl as a git submodule, and put it in the
path so that it is available if libav wants it.
Switch back to providing $CC as $AS by default, but
respect an external $AS setting so that it can be
overridden in cerbero
https://bugzilla.gnome.org/show_bug.cgi?id=694416
This should help libtool in getting the internal linking right.
Effectively, libtool can sometime get the link order wrong when
presented with a mix of .la and -l arguments. These .la file are
also required by the android build system and were previously
created by cerbero.
In the last iteration, we kept the original method to link the shared
plugin and edited the .a and .la files so satisfy what cerbero needed.
Unfortunately, that required adding .a file into the archive which is
not allowed with iOS ar command for universal builds.
This patch uses standard method to link a static library. One of the
benefit is that it removes some libtool warning about portability.
For the static case, we implement an install hook that installs
FFMPEG internal .a files in the plugin directory (so it does not get
confused with a possible system FFMPEG. This makes the static plugin
usable without depending on cerbero recipe.
This reverts commit 1a265f029a.
It also makes it impossible to pass something other than $CC
as the assembler. People should adjust the passed AS variable
if they need something different.
For arm 'host_os' is '*-gnueabi' or '*-gnueabihf' so sed needs to cut of
more. Otherwise configuring ffmpeg will fail with "Unknown OS 'linuxeabi'."
or something like that.
https://bugzilla.gnome.org/show_bug.cgi?id=774215
Otherwise it will pick it up when the system has the relevant headers,
and then linking produces an unusable plugin later as we don't ensure
that the plugin also links against the crystalhd library.
https://bugzilla.gnome.org/show_bug.cgi?id=769809
Libav-incompatible changes were introduced to support
FFmpeg and we can no longer properly support Libav.
FFmpeg micro versions for libav* start at 100 (this was
done to differentiate from Libav builds). We use this
to bail at configure time if the system libav* libraries
are not provided by FFmpeg.
https://bugzilla.gnome.org/show_bug.cgi?id=758183
