Meson now explicitly blacklists pkg-config.bat from Strawberry Perl and
thus building GStreamer on Windows has been fixed.
This allows for instance to build GStreamer on GitHub Action Windows
runners that have Strawberry Perl by default.
It is also useful when needing to build OpenSSL on the same Windows
machine because it requires Perl.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1263>
For monorepo build and ugly/bad, for advanced feature
option API like get_option('xyz').required(..) which
we use in combination with the 'gpl' option.
For rest of modules for consistency (people will likely
use newer features based on the top-level requirement).
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1084>
Due to a bug, meson ignores ${lang}_std settings in default_options
for subprojects: https://github.com/mesonbuild/meson/issues/1889
This causes build failures when a subproject requires c++11 or c++14,
etc. Compilers that support those cpp_stds are very common, and all
the toolchains that we support include c++ compilers, so we can
add cpp_std=c++14 to the top-level.
This fixes the webrtc-audio-processing build on Linux, and harfbuzz on
macOS.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1133>
Since 547570cd79 we do not always build
PyGObject and our development environment is broken when trying to use
GStreamer python when built against system PyGObject with the following
error importing Gst in there:
```
12345678** (gst-plugin-scanner:710617): CRITICAL **: 11:45:02.343: can't find gi.repository.Gst
Traceback (most recent call last):
File "/usr/lib/python3.9/site-packages/gi/repository/__init__.py", line 23, in <module>
from ..importer import DynamicImporter
File "/usr/lib64/python3.9/site-packages/gi/importer.py", line 33, in <module>
from .overrides import load_overrides
ImportError: cannot import name 'load_overrides' from 'gi.overrides' (/var/home/thiblahute/devel/gstreamer/gstreamer/subprojects/gst-editing-services/bindings/python/gi/overrides/__init__.py)
Factory Details:
```
The approach to fixing it is to implement override `gi` in
`gst-python/gi/` which we add to `PYTHONPATH`) and in there reset the
`gi` module to the right place and we get overrides from paths from
`_GI_OVERRIDES_PATH` we set in `gst-env.py` which points to all the
overrides that will be installed.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1155>
If pygobject is available on the system, its version is new enough,
don't build the older pygobject and rely on that system one.
This fixes totem not being able to use libpeas' Python support.
** (totem:544972): WARNING **: 12:04:05.407: Error initializing Python Plugin Loader: PyGObject initialization failed
ImportError: could not import gobject (version mismatch, 3.40.1 is required, found 3.38.1)
Closes: #806
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1135>
These options allow to select a set of features from a given
plugin with the following syntax:
-Dgst-full-plugins=plugin1;plugin10
-Dgst-full-elements=plugin2:element1,element2
-Dgst-full-typefind-functions=plugins3:func
-Dgst-full-device-providers=plugin4,dp1
-Dgst-full-dynamic-types=plugin5:dt1
By default all the enabled plugin are registered and
gst-full-plugins will allow to include only a set of plugin
If a feature(element, typefind etc.) is selected from a plugin,
the plugin is removed from the plugins list.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-build/-/merge_requests/199>
These get added to *all* subprojects, including ones we do not
maintain such as ffmpeg which then emits thousands of warnings that
completely overwhelm the compile output.
We will add these in each gstreamer subproject separately.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-build/-/merge_requests/223>
In a fully static link where an app link with gstreamer-full
the gst_init_static_plugins can be discarded because
no one references it.
Indeed the symbol is looked up by gst_init to call if it exists
and so it is not clearly referenced.
In order to avoid this issue, we use the linker flag
--undefined=gst_init_static_plugins to keep
the symbol.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-build/-/merge_requests/207>
Can be used to control the exact symbols exported, or not, in
libgstreamer-full.
This is useful when building a tailored libgstreamer-full aimed
to be run with some specific binaries. By using such version script
one can reduce the size of the generated lib by letting the linker
garbage collect all the unused APIs.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-build/-/merge_requests/195>
That header is not needed any more because gst_init() now calls
gst_init_static_plugins() automatically when available.
This is an API break compared to 1.18, but release notes made it clear
it was an experimental feature.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-build/-/merge_requests/191>
If a static build is requested and x264 plugin has been enabled
the full link fails with:
/usr/bin/ld: subprojects/x264/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
Fixes#108
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-build/-/merge_requests/169>
