GStreamermm fails to build and hasn't been updated in over 2 years, it is dead?

Platform Language bindings
,
1

Hello all,

Apologies if this is tagged incorrectly or something. In my project in which I’m using gstreamermm, the library itself fails to compile with the error

[build] /usr/include/gstreamermm-1.0/gstreamermm/register.h: In function ‘GType Gst::register_mm_type(const gchar*)’:
[build] /usr/include/gstreamermm-1.0/gstreamermm/register.h:114:9: error: argument 2 of ‘__atomic_load’ must not be a pointer to a ‘volatile’ type
[build] 114 | if (g_once_init_enter (&gonce_data)) {
[build] | ^~~~~~~~~~~~~~~~~

Google searches failed to bring up anything, but I saw on the GitLab page that someone was having the same issue as me (build fails with gcc11 (#11) · Issues · GNOME / gstreamermm · GitLab), but I also noticed that the library hasn’t been updated in over 2 years, so I was wondering if the project was basically dead. If so, then it’s dead with a version that seems to fail to compile.

2

Yes it’s unfortunately unmaintained for a few years now, and bitrotten at this point.

3

Thanks for the reply - that’s a shame, because I don’t particularly like dealing with GStreamer as a C library and I like gstreamermm, but I guess I’ll look into alternatives because I can’t even get it to build. Thanks again.

4

The Rust and Python bindings are well-maintained by the GStreamer project, if that helps in your case. And the Java and Vala bindings are well-maintained externally. I don’t know the exact status of the other language bindings.

For C++ I’d recommend creating your own smart pointers around the GStreamer objects at least.

1 Like
5

For Nim we have bindings and at least one example. But wrapping gstreamer was hard, and there may be bugs.

6

Before someone wrote a reasonably complex application with the bindings and got rid of all bugs along the way, I wouldn’t consider it production ready :slight_smile: That can easily take a couple of months of work.

7

Actually the gintro Nim bindings fail to install for latest gstreamer version from gitlab.

The reason is that we generate the fields of the GstMiniObject, which we do generally not for other Gtk classes. (For the GstMiniObjects some people really need access to fields, for other classes field access is hidden by getter ans setter functions provided by gtk.) And for the GstMiniObject the field copy*: MiniObjectCopyFunction has now a true data type, while it was just a pointer before. Nim do not really like forward references of data types, so data types referencing each other must be containing in a single type section. For GstMiniObject there are now three data types involved, MiniObjectCopyFunction, MiniObjectDisposeFunction and MiniObjectFreeFunction. That seems to be one more than the generator script currently can handle. But fixing that should be not hard. Maybe a better solution would be to do not write the fields of GstMiniObject but provide getter and setter functions.

type
  MiniObject00* {.pure.} = object
    `type`*: GType
    refcount*: int32
    lockstate*: int32
    flags*: uint32
    copy*: MiniObjectCopyFunction
    dispose*: MiniObjectDisposeFunction
    free*: MiniObjectFreeFunction
    privUint*: uint32
    privPointer*: pointer
8

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.