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
Only hide GstTracer and GstTracerRecord API behind GST_USE_UNSTABLE_API,
but don't spew any warnings, otherwise everyone has to define this
to avoid compiler warnings.
This reverts parts of commit 89ee5d948d.
GstPtpClock implements a PTP (IEEE1588:2008) ordinary clock in
slave-only mode, that allows a GStreamer pipeline to synchronize
to a PTP network clock in some specific domain.
The PTP subsystem can be initialized with gst_ptp_init(), which then
starts a helper process to do the actual communication via the PTP
ports. This is required as PTP listens on ports < 1024 and thus
requires special privileges. Once this helper process is started, the
main process will synchronize to all PTP domains that are detected on
the selected interfaces.
gst_ptp_clock_new() then allows to create a GstClock that provides the
PTP time from a master clock inside a specific PTP domain. This clock
will only return valid timestamps once the timestamps in the PTP domain
are known. To check this, the GstPtpClock::internal-clock property and
the related notify::clock signal can be used. Once the internal clock
is not NULL, the PTP domain's time is known. Alternatively you can wait
for this with gst_ptp_clock_wait_ready().
To gather statistics about the PTP clock synchronization,
gst_ptp_statistics_callback_add() can be used. This gives the
application the possibility to collect all kinds of statistics
from the clock synchronization.
https://bugzilla.gnome.org/show_bug.cgi?id=749391
