Request: gstreamer builds

[1480c1]

I'm thinking of adding gstreamer as a package to be built so that way we can use the libs from the suite, but was wondering if there would be any interest/caveats to it?

Currently trying to see if I can replicate gst-build with the compile script, however gstreamer fails to build due to PKG_CONFIG being exported as pkg-config --static since g-ir-scanner seems to ignore the PKG_CONFIG passed to meson (possibly revert f3347819e32ffc7ce7f6ae1e04bb686bc68aa397)

Even with PKG_CONFIG set to pkg-config, since it doesn't pull the static flags, linking errors with undef refs to static glibc, ffi, iconv, and pcre symbols

[1480c1]

I'm not exactly sure if we can include all of the plugins due to possible license issues, but probably at least base and good(?)

[1480c1]

Also not sure if I can force meson to build shared since even with default libs unset or set to shared, it tries to build static, so I need to see how to actually force shared

[moisespr123]

I'd personally want to see the suite be as complete as possible 🙂

[wiiaboo]

Sure, as long as it's completely optional, since FFmpeg/mpv don't use it.

[1480c1]

It seems I might not be able to build gstreamer with out suite due to similar problems with https://github.com/m-ab-s/media-autobuild_suite/issues/911 since it's not linking to glib and libiconv properly.

[1480c1]

Plus there seems to be linking issues with __imp_g_ascii_table even with the configure route

[wiiaboo]

There's many linux things that don't really work that well when compiled statically or in mingw. What was the need for gstreamer?

[1480c1]

When compiling with meson, gcc errors out with undefined symbols with libiconv prepended and glib macros. When compiling using the autotools route, gcc errors with undef symbols of __imp_g_ascii_table. So I'm assuming the first one is related to the meson static linking etc. The second one might be related to us hiding shared libs, or something because after searching online, there was one saying that if it's missing that symbol, the glib install might be broken.

Going to test if unhiding libs might work.

[1480c1]

As an aside, gstreamer compiled fine in a normal msys2 install both ways

[wiiaboo]

If we need to unhide libs for this, there's not much point to not use msys2's instead. Or do you really need a newer-than-release gstreamer?

[1480c1]

I'm thinking of just using msys2's instead and just compile the plugins that might come with some of the projects that are already built

[1480c1]

Although there is the question of should we try to redirect pacman to use the local64 as the root or not

[1480c1]

Actually, it seems that it might be related to https://github.com/msys2/MINGW-packages/issues/988.

Applying -DGLIB_STATIC_COMPILATION to CFLAGS works for the _imp_g_ascii_table, but now I'm facing issues with undef __imp_g_param_spec_types

[1480c1]

Adding -DGOBJECT_STATIC_COMPILATION worked...

[wiiaboo]

If you manage to add rsvg too that would be cool. FFmpeg can use it to support svg, somehow.

[1480c1]

I can try

[1480c1]

@wiiaboo, should I add qt5 to the gstreamer builds? The qt5-static binary from msys2 is almost 8GB

[wiiaboo]

Not unless necessary. There used to be mkvtoolnix compilation which required qt5 and it was a major pain in the ass because the dev was also an ass and refused to support any non-official builds. I promptly removed mkvtoolnix and pointed to the official nightly builds.

What do you want qt5 for?

[1480c1]

Just wondering if we should care about adding in those kinds of graphical libs to stuff like gstreamer

[wiiaboo]

Criteria is: avoid as much as possible. qt5 is a huge dependency, shared or static. And it's constantly being updated by msys2. So it's not just the initial 8GB, it's the bi-weekly or at least monthly 8GB for each new version.

[1480c1]

Yeah I'm not going to include it since installing it locally took a long time even with an ssd with the pkg downloaded locally