@carl

Can you test that a scratch build for epel9-next would fix it ? It's well possible that there is a need to update libplacebo to a newer counterpart (would break ABI).
vlc and mpv would need a rebuilt...

Scratch build on-going:
https://koji.fedoraproject.org/koji/taskinfo?taskID=113481683

c++filt _ZN7glslang10InitThreadEv
glslang::InitThread()

So despite the name, it's not tight to the glslang version...

Using f37 branch with newer libplacebo 4 targeting epel9-next also fails
https://koji.fedoraproject.org/koji/taskinfo?taskID=113488685

Newer fedora branches will mandates glad2 and libdovi, both importable in epel9
But vlc will not compile against libplacebo-6...


All in all, I think it would be better to backport the needed patch, (that probably consist on enabling C++17).
Is this expected as part of the glslang rebase ?

---
/usr/include/glslang/Include/SpirvIntrinsics.h:120:10: error: ‘variant’ in namespace ‘std’ does not name a template type
  120 |     std::variant<const TIntermConstantUnion*, const TType*> value;
      |          ^~~~~~~
/usr/include/glslang/Include/SpirvIntrinsics.h:120:5: note: ‘std::variant’ is only available from C++17 onwards
  120 |     std::variant<const TIntermConstantUnion*, const TType*> value;

---

g++ default to c++17 for epel9
I remember a libplacebo bug where c++11 was forced more as a minimal required version than a mandatory version, but I will double check...

> Can you test that a scratch build for epel9-next would fix it ?

Interestingly, even just rebuilding libplacebo in epel9 against rhel9 doesn't work at the moment.  The current published libplacebo was built with glslang-11.5.0-2.20210623.gitae2a562.el9, but it now fails with glslang-11.9.0-5.el9 (rhel9) and glslang-13.1.1-1.el9 (c9).

> Newer fedora branches will mandates glad2 and libdovi, both importable in epel9
> But vlc will not compile against libplacebo-6...

It may be that the best route will be to file an incompatible upgrade request with the EPEL Steering Committee to rebase libplacebo, vlc, and mpv to the latest versions from Fedora (and adding glad2 and libdovi at the same time).  If the glslang rebase in RHEL forces that, we don't really have a choice.

> All in all, I think it would be better to backport the needed patch, (that probably consist on enabling C++17).

If you think you can figure out a backport, that would be great, but I don't personally have the C++ expertise to do so.

> Is this expected as part of the glslang rebase ?

No idea, all I know about the glslang rebase is what is contained in that jira issue I linked.  glslang-devel is part of CRB so there are no guarantees about ABI stability.

I did some experimentation in copr.  Like you mentioned, in order to do newer libplacebo builds I needed to build several things that are not currently in EPEL 9, like python-glad2 and some rust crates [0].  After completing those, in separate coprs I got working combinations of glslang, libplacebo, and mpv for RHEL 9 and CentOS Stream 9.

The working combination for RHEL 9 [1] was:

glslang-11.9.0-5
libplacebo-5.264.1-2
mpv-0.36.0-4

The working combination for CentOS Stream 9 [1] was:

glslang-13.1.1-1
libplacebo-6.338.2-1
mpv-0.37.0-4

Other combinations did not work for me, such as building libplacebo 5 with glslang 13.  However, I was able to run the first combination (libplacebo 5 and mpv 0.36, built on RHEL 9) on CentOS Stream 9.  If we rebase to those version before RHEL 9.4 is released, that will allow us to stay on libplacebo 5.  Any builds after that point will require rebasing to libplacebo 6 due to glslang 13.  Going from libplacebo 4 to 5 would still be an soname change rebase and require following the incompatible upgrades process [3].  Does that sound like a good plan?


[0] https://copr.fedorainfracloud.org/coprs/carlwgeorge/libplacebo/builds/
[1] https://copr.fedorainfracloud.org/coprs/carlwgeorge/libplacebo5/builds/
[2] https://copr.fedorainfracloud.org/coprs/carlwgeorge/libplacebo6/builds/
[3] https://docs.fedoraproject.org/en-US/epel/epel-policy-incompatible-upgrades/

Does the undefined symbol error also occurs with RHEL or is it just a FTBFS issue ?

I confirm that just changing the default c++11 to c++17 in meson doesn't fix the build with current libplacebo 4. At which point if a change needs to occurs, best is to switch to libplacebo5 (that also have the same hack with 85aee9d0)


If landing libplacebo-5 (merged from f38), it might be possible to cherry-pick 85aee9d0 to fix build with gslang 13 ?
(would need glad2 to test)...


libplacebo5 would be more interesting as a longterm version as it will keep supporting vlc-3

> Does the undefined symbol error also occurs with RHEL or is it just a FTBFS issue ?

Currently the undefined symbol error does not occur on RHEL 9.3.  When RHEL 9.4 is released, the problem will start occurring on RHEL too.  CentOS Stream 9 at this point is basically RHEL 9.4, so it is already a problem there.  So for now, it's just a FTBFS issue on RHEL 9, but in the near future it will be a runtime issue as well.  Rebuilding with libplacebo 5 fixes the runtime error on 9.4, but there will still be FTBFS issue after 9.4 is released.

> libplacebo5 would be more interesting as a longterm version as it will keep supporting vlc-3

I'm not sure if you were just talking about updating libplacebo to version 5, or suggesting a libplacebo5 compat package, but I think the later is actually a great idea.  I was able to set this all up, adding the missing build requirements, creating a libplacebo5 compat package, and rebuilding mpv against it.  I tested the results and confirmed that it resolves the undefined symbol error in mpv running on CentOS Stream 9.  Let me know if you'd like to become a co-maintainer of libplacebo5, I'd be happy to add you.

FEDORA-EPEL-2024-e74bd24903 (libplacebo5-5.264.1-1.el9, mpv-0.35.1-3.el9, and 6 more) has been submitted as an update to Fedora EPEL 9.
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2024-e74bd24903

For the future FTBFS issue once RHEL 9.4 is released, there are two different ways we could handle it.  Normally for compat packages in EPEL, I prefer to create the compat package equivalent to the existing package, then rebase the existing package to the higher version.  In this case that would mean rebasing libplacebo from 4 to 6, leapfrogging the libplacebo5 compat package.  Alternatively, we could leave libplacebo frozen in time on version 4, with no ability to rebuild, and add a libplacebo6 compat package.  Either way, mpv and vlc (and any other packages) would be free to build against any version.  For example, mpv could move on to building against libplacebo(6) while vlc continues to build against libplacebo5.

Which way would you prefer Nicolas?

I'm not sure to understand why you need to bump libplacebo to 6 before RHEL 9.4 given glslang is already in CentOS Stream 9 ?

I expect when RHEL 9.4 is released that libplacebo from epel9-next will need to be merged into epel9 (and a build submitted)

Libplacebo 6 looks anachronistic on epel9

FEDORA-EPEL-2024-e74bd24903 has been pushed to the Fedora EPEL 9 testing repository.

You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2024-e74bd24903

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

FEDORA-EPEL-2024-e74bd24903 (libplacebo5-5.264.1-1.el9, mpv-0.35.1-3.el9, and 6 more) has been pushed to the Fedora EPEL 9 stable repository.
If problem still persists, please make note of it in this bug report.

> I'm not sure to understand why you need to bump libplacebo to 6 before RHEL 9.4 given glslang is already in CentOS Stream 9 ?

We don't need to bump libplacebo from 4 to 6 *before* RHEL 9.4.  The new libplacebo5 package I added resolved the urgent mpv error.

However, libplacebo (4) is already FTBFS, meaning if it has a security issue we can't rebuild it, even if the patch is simple.  Once RHEL 9.4 is released, libplacebo5 will also become FTBFS and have the same problem.  At that point I think having version 6, either by introducing libplacebo6 or updating libplacebo from 4 to 6, would make sense.

> I expect when RHEL 9.4 is released that libplacebo from epel9-next will need to be merged into epel9 (and a build submitted)

I didn't actually build any of this in epel9-next.  That's what I thought would be needed at first, but once I got deeper into investigating it I realized that libplacebo5 built against RHEL 9.3 with glslang 11.9 would work at runtime on CentOS Stream 9 with glslang 13.1.

If you aren't interesting in rebasing libplacebo to version 6, then we can just add libplacebo6 later once it becomes necessary.

> Once RHEL 9.4 is released, libplacebo5 will also become FTBFS
Yep that's the very point I don't get, but now I got it. You've introduced newer libplacebo as libplacebo5, but this is awful. One cannot mix multiple libraries in a same process and having them is paving the way for this terrible miss-take.


I thought you were going to update libplacebo to 5 and rebuilt and clear the possibility to keep libplacebo at version 4 at all.

> libplacebo5 would be more interesting as a longterm version as it will keep supporting vlc-3
I meant libplacebo package at version 5, never meant a libplacebo5 package, sorry if the confusion comes from here.

Now every packages provided in EPEL9 are libplacebo5 based, So I think we can assumes libplacebo5 is the "current version".

I would suggest to rebase to earlier libplacebo 6 release before vlc breakage and upgrade libplacebo package to libplacebo 6.x on RHEL 9.4 GA.

That way, the libplacebo5 package can be deprecated and only one libplacebo release could be used on epel9

> You've introduced newer libplacebo as libplacebo5, but this is awful.

Disagree.

> One cannot mix multiple libraries in a same process and having them is paving the way for this terrible miss-take.

Having multiple libplacebo packages is not going to cause this.  The devel packages conflict with each other, cannot be installed at the same time, and thus can't be linked to from the same binary and end up in the same process.

> I thought you were going to update libplacebo to 5 and rebuilt and clear the possibility to keep libplacebo at version 4 at all.

libplacebo can stay on version 4 if you like, but it will be worthless if it starts crashes other applications like it did mpv.

> I meant libplacebo package at version 5, never meant a libplacebo5 package, sorry if the confusion comes from here.

It's fine, I actually think the separate libplacebo5 package makes more sense anyways.

> That way, the libplacebo5 package can be deprecated and only one libplacebo release could be used on epel9

Didn't you say that vlc is incompatible with libplacebo 6?  So we need to keep libplacebo 5 around in some form regardless, and libplacebo5 is perfect for that while we update libplacebo to version 6.

>  thus can't be linked to from the same binary...
FULL NAK on this. The problem with multiple ABI incompatible libraries is never about when linking binaries, but when a 3rd library links to one or another. If your binary also links to this 3rd library but with the wrong

And the problem arise more often than not, and specially it can happens here.


Let's get this easier. I'm NOT going to accept libplacebo 6 for epel9 unless any real issue given the RHEL/CentOS Stream constrains, please wait on RHEL10 for that.
I'm going to update libplacebo to latest 5 and discard libplacebo5. There is no reason to keep both incompatible library

Compatibility packages are quite common in Fedora, RHEL, and EPEL, and are allowed by all relevant policies.  If you don't want to update libplacebo from 4 to 6, then I'll add a separate libplacebo6 compatibility package.  This is necessary so that mpv can build against a libplacebo library that can be patched for security issues (i.e. not FTBFS).  Being in a FTBFS state is a real issue that needs attention, and it worries me that you would dismiss such an issue out of hand.

It's pretty rude to tell another packager that you're going to "discard" their package.  That's not a productive way to work with other packagers.  If you want to update libplacebo from 4 to 5 and obsolete libplacebo5, then let's work together to do it appropriately following the incompatible upgrades process [0].


[0] https://docs.fedoraproject.org/en-US/epel/epel-policy-incompatible-upgrades/