gstreamer1-gst-plugins-good @ 1.24.1 -x11: Conflicting header file of dependencies mesa and gl-headers

[FlyingSamson]

Building gstreamer1-gst-plugins-good with -x11 +no_x11 +quartz in the variants.conf file results in a failure to activate mesa (recursive dependency through gtk3), because it tries to install the header <prefix>/include/GL/glext.h which is already provided through the gl-headers port (recursive dependency through gstreamer1-gst-plugins-base).

Related PR: ​23502

Error message:

--->  Activating mesa @22.1.7_2
      [                                        ]  34.5 %Error: Failed to activate mesa: Image error: /opt/macports-test/include/GL/glext.h is being used by the active gl-headers port.  Please deactivate this port first, or use 'port -f activate mesa' to force the activation.

Full log attached below.

[FlyingSamson]

Mesa build log

[ryandesign (Ryan Carsten Schmidt)]

Hasn't this already been dealt with by [f9b41b50457a271e1c070c79753a7c0be016c26a/macports-ports] and [c7cbe09c6584ffcdda282c4524b669aa6f4bffe8/macports-ports]? You should not have been able to get to this point; MacPorts should have alerted you earlier that mesa conflicts with gl-headers.

[FlyingSamson]

That is odd. No, it did not warn me or anything. I even retried this in an entirely fresh installation of macports using a different prefix and it ran just fine until trying to activate mesa.

Does that mean gstreamer1-gst-plugins-good is (at least currently) not supposed to be available using quartz instead of x11? Is there hope (maybe even something I could do) that it will become available again?

I'm currently trying to first install mesa and then gstreamer1-gst-plugins-good (still building). From what I gathered this should work, as then gstreamer1-gst-plugins-base won't pull in the dependency to gl-headers and use the mesa provided ones instead. But of course this, at best, is only a workaround, because as soon as any other already installed port pulled in gl-headers, the mesa dependency of gstreamer1-gst-plugins-good cannot be satisfied.

[ryandesign (Ryan Carsten Schmidt)]

Replying to FlyingSamson:

That is odd. No, it did not warn me or anything. I even retried this in an entirely fresh installation of macports using a different prefix and it ran just fine until trying to activate mesa.

Does that mean gstreamer1-gst-plugins-good is (at least currently) not supposed to be available using quartz instead of x11? Is there hope (maybe even something I could do) that it will become available again?

I don't know. I think we need some clarification from @Gcenx who added the gl-headers ports.

Why was the gl-headers port added? What does it provide that the existing mesa port doesn't have?

There are 77 ports that depend on mesa and one port (gstreamer1-gst-plugins-base) that depends on gl-headers, and mesa and gl-headers conflict. What's clearly going to happen, and has happened here, is that MacPorts has resolved the dependencies of the one port that depends on gl-headers (gstreamer1-gst-plugins-base) first, and therefore installed gl-headers. Then, when it comes time to install any of the 77 ports that depend on mesa, it fails since there is a conflict. It should clearly state that there is a conflict before attempting installation but something is going wrong so that that isn't happening, so the problem surfaces at activation time instead.

The solutions that I see are to delete the gl-headers port and have gstreamer1-gst-plugins-base depend on mesa instead, or, if gl-headers provides something gstreamer1-gst-plugins-base needs that mesa doesn't have, change gl-headers so that it installs those things in places that don't conflict with where mesa installs things.

I'm currently trying to first install mesa and then gstreamer1-gst-plugins-good (still building). From what I gathered this should work, as then gstreamer1-gst-plugins-base won't pull in the dependency to gl-headers and use the mesa provided ones instead.

Yes, that's what I would suggest too. If that succeeds, I would take it as evidence that the gl-headers port is not needed and could be deleted.

[FlyingSamson]

Building mesa first and then gstreamer1-gst-plugins-good worked as expected.

Thank you, for your thoughts on this.

I made a quick diff on the conflicting headers and while one of the three headers provided by gl-headers (the very only files installed by this port) is equivalent to the one provided by mesa the other two differ. This might suggest, that there is something special about the headers provided by gl-headers that the mesa provided ones miss, but I'm no expert on this by any means.

[Gcenx]

The upgraded gstreamer1 ports where never tested building for -x11 so there’s going to be other conflicts, another example is gstreamer1-gst-plugins-bad can’t really be built for -x11 as it always pulls in libGLU & mesa.

[FlyingSamson]

I see. But irrespective of further issues with other ports, wouldn't the idea by ryandesign of letting gstreamer1-gst-plugins-base directly depend on mesa in case of -x11 be worth considering? I mean the way it is now, when somebody installed gstreamer1-gst-plugins-base either directly or as dependency, he will automatically pull in gl-headers which is also only required by this very port and then be unable to install any of the ports that depend on mesa afterwards. On top comes the confusing fact that if he would have first installed a port depending on mesa, everything would work out just fine.

From what I could see mesa also does not incur any other conflicts that otherwise would be avoided by depending on gl-headers instead.

So unless there is something to be gained from depending on gl-headers this appears a good and easy fix to me.

I also just saw that the gtk3 port seems to be doing a similar thing of depending on mesa in case of -x11 +quarzt when it should only be required for +x11, or at least that is how I understand this comment

# mesa required to configure both +x11, +quartz (not just +x11) due to their dependency on libepoxy
depends_lib-append  port:mesa

in its Portfile.

[kencu (Ken)]

the way the gstreamer* ports were updated three weeks ago was destined to lead to these troubles

​https://github.com/macports/macports-ports/pull/22425

we should remember this next time there is pressure to commit a PR with about 60 port updates in it, some of which were noted in the PR to clearly have ssues.

[Gcenx]

The entire idea of passing -x11 is to avoid installing things like mesa, realistically each port that pulls in x11/mesa libraries should be corrected to those are only added when +x11 is set.

Replying to kencu:

the way the gstreamer* ports were updated three weeks ago was destined to lead to these troubles

​https://github.com/macports/macports-ports/pull/22425

we should remember this next time there is pressure to commit a PR with about 60 port updates in it, some of which were noted in the PR to clearly have ssues.

The actual issue shown in this ticket is really due to macports default of +x11 and ports now been tested with -x11, that should be avoiding x11/Mesa libraries when set but that’s not the case.

Also the updated gstreamer1 ports are much worse, they’ll opportunistically link to many libraries as the meson arguments are lacking.

gstreamer1-gst-plugins-base -x11 even without my change would conflict with mesa as gst-plugins-base would git clone gl-headers, I’m sure some of you remember I’d originally kept requesting meson default to nodownload but nobody was in favor of this.

In the gstreamer1 PR I’d express meson subprojects getting used but it was never adressed.

[kencu (Ken)]

you did recommend nodownload, but folks felt because there were so many, ports should be individually changed to that, then the default changed once they were all changed and confirmed to work that way. That effort is however stalled, tracked here #67990

how do we clean up the gstreamer — debacle? We need GL support again, we need quartz to work, we need x11 to work, we need webkit2-gtk to work, and we can’t conflict with mesa.

These ports are nomaintainer. You understand them better than most. Want to claim them, take over, and fix this up?

[Gcenx]

Replying to kencu:

you did recommend nodownload, but folks felt because there were so many, ports should be individually changed to that, then the default changed once they were all changed and confirmed to work that way. That effort is however stalled, tracked here #67990

Oh I remember why this was the case, the reason why gl-headers became a Portfile was due to us being a wrap used by gstreamer as when it’s used it will download via git meaning it would fail on older systems that don’t install modern git.

Replying to kencu:

how do we clean up the gstreamer — debacle? We need GL support again, we need quartz to work, we need x11 to work, we need webkit2-gtk to work, and we can’t conflict with mesa.

Yeah, the gstreamer1 ports are rather critical dependencies and these rushed updates are frankly awful, I’d given my two cents from the start but they look to have been configure how brew would have done them.

Replying to kencu:

These ports are nomaintainer. You understand them better than most. Want to claim them, take over, and fix this up?

I’ve been working on the gstreamer1 ports locally already, there’s still going to be other ports that need fixing so they can be installed with -x11 though.

Done of the default variants also make no sense, like why is pulseaudio enabled by default.

[FlyingSamson]

So, I tried to figure out how to get rid of the mesa dependency of gstreamer1-gst-plugins-good +quartz -x11.

It seems the only path this is pulled in is gstreamer1-gst-plugins-good -> gtk3 -> libepoxy -> mesa (as well as xorg-util-macros and xorg-libX11).

I'm really no expert (not to say I'm a total noob) regarding everything regarding x11 vs quartz, but from my googling around I'm under the impression that GLX is specific to X11, yes?

If so, may we simply put the part

    # enable GLX support
    # without this any gtk3 +x11 app will fail on load as follows
    # dyld: Symbol not found: _epoxy_glXBindTexImageEXT
    #   Referenced from: /opt/local/lib/libgdk-3.0.dylib
    #   Expected in: /opt/local/lib/libepoxy.0.dylib
    #   in /opt/local/lib/libgdk-3.0.dylib
    configure.args-append \
                        -Dglx=yes

in the Portfile for libepoxy in a if {[variant_isset x11]} {...} and also move the requirement for the three ports mesa, xorg-util-macros, and xorg-libX11 into that if statement, too?

I also moved gtk3's direct lib-dependency on mesa into an if {[variant_isset x11]} {...} statement.

My build of gstreamer1-gst-plugins-good with these changes in place went through at least, but I cannot say if by disabling the GLX support I disabled some other functionality required by dependent ports.

If you say that these changes seem sensible, I'd be happy to create a PR for libepoxy and gtk3 to have one less dependency on mesa and friends with -x11 +quartz enabled.

[FlyingSamson]

Related PR: ​https://github.com/macports/macports-ports/pull/23760