Centos7/RHEL7 support

I understand these distros are old but i was wondering nonetheless if anyone has some experience on installing the latest gstreamer on that.

The repositories have an ancient gstreamer version as expected, so i resorted to building the package from cerbero, but after many issues and having to edit the recipes manually (incompstible openssl, tar, compiler, and libsoup uses unknown C types (needs --std=gnu99 not c99 etc).

Since noone has reported those issues, can i assume those distros are not considered supported anymore? Thank you

You have few options. On RH platforms, distributing your software as a flatpak is I believe the most straightforward.

Alternatives are to rely on our cerbero build system (quite some work, as it expects to use your system), use meson subproject, but shipping your own copy of certain list can be tricky.

Various recipes and even GStreamer require patches for building with the ancient toolchain on RHEL7. I think there’s some code that even ends up in an ICE in gcc with the version that comes with RHEL7. I don’t think this is something we want to officially support upstream as it’s a lot of effort for a small percentage of users who decided to use an “enterprise” distribution.

It’s doable to build GStreamer (and all of cerbero) on RHEL7, especially if you can use a toolchain from one of the more recent devtoolsets. But that’s IMHO something your system integrator should do for you (or you if that’s your job). That’s part of the enterprise deal after all.

Also quite simple, without CI for this we won’t even know if something breaks. Anything that is not tested by the CI is effectively unsupported.

2 Likes

Thank you, i have already tried to use cerbero but unfortunately there are some hurdles.

  1. You need to build a newer python version from source, centos7 has old python and cerbero needs 3.8+.

  2. The system tar is old and breaks during packaging because of an “exec”. i installed a newer manually

  3. All recipes unfortunately use system openssl without checking compatibility or giving an otpion for external openssl. i had to manually edit all recipes and remove the condition “if on linux, use system openssl”.

  4. Libsoup version used by cerbero has a bug where it uses nonstandard C types without specifying “gnu99”. I had to make a manual patch.

  5. You need devtoolset for a newer GCC than 4.8.5 but thats to be expected.

So i since i saw some “centos7 compatibility” mentions in the release notes i thought someone actually builds and tests on centos7 and maybe a package was out there.

By the way my end goal is to give gstreamer to centos clients along with my app, not personal use.

Ship them a flatpak, it’s the best user experience you can offer.

Hah, apparently it’s not ok to “require” the customer to install and use flatpak.

I think i will go with a custom fork of cerbero that has my changes, but it would help a lot if there was an option to build openssl instead of use the system’s since the recipe exists.

An alternative you might want to look into is using docker instead of flatpack if it’s a non-UI application.

But that sounds like it’s exactly your job as system integrator to make things somehow work on the troublesome environment of your customers.

That’s what I’m doing for one of our customers (plus new devtoolset, newer Python from EPEL, …). But the changes are not pretty at all so I’d rather not have them upstream as they’re in the end just hacks to somehow make things work with broken toolchains.

That can be changed relatively easily but are you sure your customers want to have a custom OpenSSL version and not the one that gets support from RH?

1 Like

As far as i know there is no way to officially get 1.1.x on either of these systems so using a custom build is their only option if they refuse to update.

Instead of making this specific to openssl, would it be possible to allow the user to prepend pkg_config_path in cerbero? It seems the env var is completely overriden in Config.py. That would help with any needed system library with minimum change. Thank you for your help.

@slomo @ndufresne sorry to mention this here but just to avoid making a new thread, when building the packages with cerbero myself, there are lots of references and paths to my original build directory

E.g gst-validate-launcher has BUILDIR and SRCDIR paths /home/username/repos/cerbero/build/sources…

Am i missing something in order to remove any traces of my personal workstation? I am using the sample cerbero.cbc and linux config

This is a long known issue with cerbero design. The only workaround I know is to set the config.prefix to something you like, could be /opt/gstreamer, make sure that you build user have appropriate permissions.

I have already set the prefix, and that leads for example in some references pointing there. But others, like “BUILDDIR” in gst-validate-launcher or using “strings” command inside libraries, all reference my original pc build dir.

Debug symbols are like this, and the launcher BUILDIR is probably used for backtraces. If it’s just about anonymous build, use a container.