Add new GST_API_EXPORT in config.h and use that for GST_*_API
decorators instead of GST_EXPORT.
The right export define depends on the toolchain and whether
we're using -fvisibility=hidden or not, so it's better to set it
to the right thing directly than hard-coding a compiler whitelist
in the public header.
We put the export define into config.h instead of passing it via the
command line to the compiler because it might contain spaces and brackets
and in the autotools scenario we'd have to pass that through multiple
layers of plumbing and Makefile/shell escaping and we're just not going
to be *that* lucky.
The export define is only used if we're compiling our lib, not by external
users of the lib headers, so it's not a problem to put it into config.h
Also, this means all .c files of libs need to include config.h
to get the export marker defined, so fix up a few that didn't
include config.h.
This commit depends on a common submodule commit that makes gst-glib-gen.mak
add an #include "config.h" to generated enum/marshal .c files for the
autotools build.
https://bugzilla.gnome.org/show_bug.cgi?id=797185
Instead, use -fvisibility=hidden and explicit exports via GST_EXPORT.
This should result in consistent behaviour for the autotools and
Meson builds where this is done already, and will allow us to drop
the win32 .def files.
`./configure --disable-gst-tracer-hooks` didn't do anything, hooks were
always enabled regardless of the option. It works correctly in the
Meson build though.
This patch reorganize the bash completion scripts in order to install
the binary helper (gst-completion-helper) in libexec path rather then
share folder. Most Linux hierarchy compliance requires that no binary
executable are placed in share. We also cleanup the unused .pc entries
and remove copy pasted parts of the script. Note that other project
including the common helper, should now use $_GST_HELPER to read
the binary executable gst-completion-helper. This helper is not longer
version, as it is placed in a versionned subfolder
(libexec/gstreamer.10) just like the other helpers (scanner and ptp).
clock_gettime was also added for iOS 10.0, so don't use it if we're
targetting an older version. That would've caused the symbol to not be
found at runtime on older devices.
With XCode 8, clock_gettime will be incorrectly detected as being
available regardless of what OS X version we're targetting because the
symbol is available in the .tbd library as a weak symbol.
See: https://github.com/Homebrew/homebrew-core/issues/3727#issue-170086273
It's only starting from macOS 10.12 that clock_gettime is actually
available, so we can unconditionally disable it when targetting older
versions. We cannot simply do AC_CHECK_FUNCS with -Wl,-no_weak_imports
because the autoconf check does its own prototype declaration that
doesn't trigger that compiler flag.
https://bugzilla.gnome.org/show_bug.cgi?id=772451
Earlier we were only using __declspec(dllexport/import) when we were
built with MSVC because when built with MinGW and linking with MinGW we
don't need it (and we get linker errors because of it).
However, when we're built with MinGW and someone wants to link to us
with MSVC, we still need the prototypes to have __declspec(dllimport)
since MSVC cannot do auto-import like GCC can.
https://bugzilla.gnome.org/show_bug.cgi?id=771029
We only use GST_EXPORT consistently when building with MSVC by using the
visual studio definitions files (win32/common/*.def), so always disable
it when building with Autotools and only enable it with Meson when
building with MSVC.
This allows you to use MinGW to link to a GStreamer built with MSVC and
get the correct function prototypes to find functions and variables in
DLLs.
This makes gstconfig.h completely arch-independent. Should cover all
compilers that gstreamer is known to build on, and all architectures
that I could find information on. People are encouraged to file bugs if
their platform/arch is missing.
If the prototypes in the public API have dllimport in them when building
statically on Windows, the compiler will look for symbols with symbol
mangling and indirection corresponding to a DLL. This will cause a build
failure when trying to link tests/examples/etc.
External users of GStreamer also need to define -DGST_STATIC_COMPILATION
if they want to link to static gstreamer libraries on Windows.
A similar version of this patch has been committed to all gstreamer
repositories.
https://bugzilla.gnome.org/show_bug.cgi?id=767463