gtk4: "No provider of glGenSamplers found" error on older systems

[barracuda156]

Installed an update to pavucontrol now, and it fails to run:

No provider of glGenSamplers found.  Requires one of:
    Desktop OpenGL 3.3
    GL_ARB_sampler_objects
    OpenGL ES 3.0
zsh: abort      pavucontrol

GTK3 version launched normally.

Is it possible to fix GTK4? If not, then it should be handled like with Qt4/Qt5, pegging unsupported systems to GTK3.

[barracuda156]

Ok, I have found at least an ugly way to make GTK4 work: ​https://gitlab.gnome.org/GNOME/gtk/-/issues/1339

Passing GSK_RENDERER=cairo in env fixes the problem and the app starts normally.

This should be at least added to port notes.

UPD. Nah, I was too fast. It starts the GUI, but does not work. GUI is frozen and does not react to anything. (The OS itself works normally, so system freeze.)

[barracuda156]

UPD2. It is kinda working, but slow. So unless there is a better way, GSK_RENDERER=cairo is okay as a temporary fix.

[mohd-akram (Mohamed Akram)]

See also - ​https://gitlab.gnome.org/GNOME/gtk/-/issues/5858

[barracuda156]

Replying to mohd-akram:

See also - ​https://gitlab.gnome.org/GNOME/gtk/-/issues/5858

I do not have a real use-case to compare (for that I need some port which I use with GUI to have both versions), but if the worst outcome is having to use Cairo backend which will be as fast/slow as in GTK3, then there is no big issue, but we need to issue a warning to users to use an env variable.

A perspective of having to add per-port pegs to GTK3 is really unappealing, especially given that I will need to do that LOL

But it does seem an odd arrangement on a part of upstream to leave this broken by default and expecting a user to search online for hacks how to make it work, when in GTK3 it worked out of the box.

[mohd-akram (Mohamed Akram)]

They seem to be trying to fix it, they haven't closed the issue at least.

A perspective of having to add per-port pegs to GTK3 is really unappealing, especially given that I will need to do that LOL

This can probably be fixed in GTK 4 itself. Per-port pegs are unnecessary when it builds fine and there's a simple workaround.

we need to issue a warning to users to use an env variable.

Can probably be added to the notes.

[barracuda156]

Ok, I will make a PR to add a note until it is fixed, otherwise it is nowhere obvious and makes an impression that it is just completely defunct.

[barracuda156]

I just got the same error on macOS 14.

svacchanda@Sergeys-Air ~ % dino
No provider of glGenSamplers found.  Requires one of:
    Desktop OpenGL 3.3
    GL_ARB_sampler_objects
    OpenGL ES 3.0
zsh: abort      dino

[RJVB (René Bertin)]

Replying to mohd-akram:

They seem to be trying to fix it, they haven't closed the issue at least.

Don't count on it. The attitude of Gnome devs is well-known in this regard, and last week or so I was told that 1) GTk4/X11 apps would need compositing X11 servers (XQuartz isn't) and 2) don't use the X11 backend on Mac.

To the best of my knowledge Apple's OpenGL has remained stuck at 2.1 so there's that too. MAYBE an avenue would be to add a +egl variant to port:mesa (I hear it's trivial to get EGL to build on Mac in recent days; it was already not very difficult in v19.x). Performance for GUI effects should be good enough with the llvmpipe renderer, and this approach stands a chance to support remote displaying too (a main reason to use GTk/X11?). A word of warning: the EGL code path would have to initialise GLX too on Mac, to be certain that Mesa's libGL.dylib gets loaded/initialised instead of Apple's own. I ran into that with my testing of updated webkit2-gtk (2.40.x) with EGL enabled; at best the application crashes but I also had a few KPs that were probably due to messing the wrong way with OpenGL.

Either way, I think the best approach here is to start providing -gtk4 or so (sub)ports (or -gtk3 legacy (sub)ports) at least for the most popular ports. Heck, even the further loss of theme choice would justify that in my book!

EDIT: re: legacy/pegged ports that encumber the tree: why not move them to their own ports tree, with a bit of documentation how to install them? Defining trees the right way in sources.conf will make pegged legacy port versions "hide" the current ones.

See also #70635 .

[barracuda156]

Replying to RJVB:

EDIT: re: legacy/pegged ports that encumber the tree: why not move them to their own ports tree, with a bit of documentation how to install them? Defining trees the right way in sources.conf will make pegged legacy port versions "hide" the current ones.

That would probably make life easier. Even better if a tree can be automatically picked for specific criteria. Thus we could at the same time get rid of overly complex portfiles with chains of fallbacks, make maintaining ports easier (both for new systems and for legacy ones), actually fix some ports which got unnecessarily broken by updates and avoid subsequent breakages (for example, until Qt5/Qt6 is fixed for powerpc, all Qt4 ports could be pegged in its tree, much simpler way than monitoring every PR in the queue) and hopefully stop preventing fixing something merely because not many people use that.

[kencu (Ken)]

I maintained portfile overlays for 10,4 and 10.5 for some years, until I lost interest and moved those machines to linux. Nobody else took over when I stopped doing it, but they could easily enough.

We have been hoping you would maintain an overlay for your 10.6-ppc interest for a long time now.