drop GSL from GStreamer and move them to GCCcore toolchain#24179
Conversation
|
Test report by @Micket |
|
Test report by @Micket |
|
@boegelbot please test @ jsc-zen3 |
|
@Micket: Request for testing this PR well received on jsczen3l1.int.jsc-zen3.fz-juelich.de PR test command '
Test results coming soon (I hope)... Details- notification for comment with ID 3387052452 processed Message to humans: this is just bookkeeping information for me, |
|
Test report by @boegelbot |
|
Test report by @Thyre |
|
Doesn't seem to cause issues with a system GSL installed (as on my machine). I generally prefer this, as this makes handling quite a few things easier... |
|
Test report by @branfosj |
|
Test report by @branfosj |
|
Going in, thanks @Micket! |
(created using
eb --new-pr)It's really frustrating that GStreamer being at GCC level pushes so several other things into GCC needlessly. GST-plugins, GTK4 etc.
These really do belong at core level, as they are in no way performance critical, and I trust GCC to be a much more reliable compiler for all the desktop GUI toolkit stuff.
GStreamer was only at GCC level due to GSL, but i traced down what it actually uses GSL for, and it's literally just some tests (that we don't even run!). Nothing in the install links to libgsl at all. I looked through the entire build log, so I'm pretty sure.
Nothing in GST-plugins either.
So, I propose we change this, move them down. Other things could be moved down if we do this.
I kept the GStreamer at version 1.26.5 for GCCcore 14.3.0, because that's what already in use, so that if someone has it build (I think we shipped it), it's going to stay compatible. So, I think this is safe to change even if someone doesn't rebuild their local GStreamer; they would just have one GCC and one GCCcore copy, and it doesn't matter which gets loaded)