While our team has been reviewing the 1.24 cerbero vs gstreamer mono repo wrap targets for GLib (internal question), we noticed that the cerbero recipe for GLib is pointing at 2.74.4 while the wrap file in the mono repo is pointing at 2.78.3.
Our question is which one is more correct? Our experience with cerbero is that the cerbero recipe will “win” and that’s what gstreamer will build against in cerbero.
We’re happy to upstream a patch to the recipe if the wrap file is the better/more correct expected version for the dependency
In general we would recommend the latest stable version you can easily get your hands on, but if it’s not the latest that’s usually fine.
Updating the GLib version in cerbero is not always straight-forward because it involves building for target architectures and configurations which the GLib folks usually don’t test themselves, so there are always things to fix, and we maintain some patches as well that are not necessarily upstreamable.
Cerbero main branch now has GLib 2.80.2, and you can check out the Merge Request to see the kind of issues that a version update involves (started out as ‘update to 2.76.x’).
For the mono repo, there is already an MR to bump the wrap to 2.82.x, but as you can see it requires some CI updates too. We’ll get around to it eventually, it’s usually not terribly important to be honest.
We’ve been maintaining a patch in our fork to disable the gslice allocations in Glib due to the issues we were having with it on Windows and have been wanting to get to a version of GLib that removed gslice in a maintained way.
We’ve got a test going now cherry picking the commit for the 2.80 change and pulling it into our forked 1.24 branch in the hopes that we can have the best of both worlds.
Interesting, first time I hear about this. Usually crashiness with gslice is caused by memory handling issues elsewhere that just manifest themselves in gslice then, but in that case one wouldn’t expect it to be limited to libnice.
You probably know it already, but you can also disable GSlice by setting the G_SLICE=always-malloc environment variable in older GLib versions.
I had posted a question way back that Olivier tackled initially. We did go the route of the environment variable but we were running into timing issues with setting the var programmatically for the process and having the libraries load with the var set correctly (not wanting to add it to the system and potentially impacting other apps/processes).
We decided that for our purposes it made sense to create a local fork and patch knowing that GLib was deprecating/removing.
