How am I supposed to use this in Linux?

[intractabilis]

The documentation indicates I have to make the following call:

glbinding::Binding::initialize(glXGetProcAddress);

What if I use GTK? I cannot even be sure if GTK uses GLX or EGL. How do I get this function address from GTK? Also, I have to make this call after the context is created. Which is when in GTK?

If I don't use GTK, am I supposed to manually load some .so and call dlsym?

[intractabilis]

After much struggle, I've decided that the best solution is to continue using libepoxy. No initialization is needed; everything works magically, whether EGL or GLX.

[scheibel]

Following your example, you like to use hardware-accelerated, but vendor-specific and platform-specific rendering APIs wrapped through OpenGL in your code. You mention GTK, which I try use to focus my answer, although it's general in nature.

Context 1 - Context Management:
OpenGL is a language-agnostic API but that does not come with cross-platform libraries per se. As a main limitation, creating an OpenGL context (together with a drawing surface and a default framebuffer) highly depends on the availability of fitting libraries on any system, such as WGL, GLX, AGL, CGL, just to mention the libraries for Windows, Linux/X11 and macOS (thereby, not even an exhaustive list). A popular solution to fragmented availability across platforms is wrapping the platform-specific features into cross-platform concepts and cross-platform features into cross-platform libraries. For OpenGL context management, we have EGL.
However, OpenGL contexts and drawing surfaces are usually considered part of an applications' GUI. As such, GUI toolkits such as glfw, SDL, GTK, and Qt provide low-barrier access to OpenGL-enabled widgets and surfaces.
Thereby, these toolkits use one kind of low-level OpenGL context management library, for example depending on operating systems and display server. Examples: Windows with DWM, macOS on Quartz, maxOS on X11, Linux on X11, Linux on Wayland, ...
As multiple display servers are available for given platforms, those cross-platform toolkits want to abstract from their underlying API to manage the OpenGL contexts.
Handling those platforms and context management APIs is cumbersome, but essential to any application with OpenGL rendering.

Context 2 - Extension Handling:
In addition to context management, OpenGL is designed and developed as a (language-agnostic) vendor-initiated, consortium-approved, extension-based API.
This allows to support cutting-edge and platform-specific features although using an independently developed API, but comes at the cost to manage those extensions as well.
Providing access to those extensions - often a preview to a standardized feature - is realized through dynamic function pointer lookup by means of specialized functions such as glxGetProcAddress, wglGetProcAddress, and eglGetProcAddress.

Problem:
Such extension handling was formerly supported by GLEW, but around 2013, multiple further projects started with the promise to solve extension-focused OpenGL usage.
Two examples are libepoxy and glbinding, both targeting the same problem.
I could grasp one major difference in handling this OpenGL context management problem: libepoxy strives to hide the dependency to the display server and the context managing API from the user, while glbinding strives for active leaky abstraction.
As such, glbinding supports that a user is aware of the underlying context managing API, but also provides fallbacks such as libepoxy.

General Answer:
The example using glxGetProcAdress is only applicable when the corresponding OpenGL context was created with GLX. Each display server provides an own function to query the extended OpenGL functions and thus, an OpenGL application depends on the underlying display server to query those functions.
I assume libepoxy guesses on which platform and with which display server it is used - falling back to dynamic symbol lookup on the current executable itself - to use the appropriate function to query OpenGL function pointers. In glbinding, we also allow for this fallback (https://github.com/cginternals/glbinding/blob/master/source/glbinding/include/glbinding/getProcAddress.h#L32), but encourage to use those platform specific APIs.

Specific Answer:
As such, I currently don't understand your need to use libepoxy as the featureset you want to use is also provided by glbinding.
You either know the platform you depend on through use on platform-specific libraries or cross-platform libraries and if they support OpenGL context management, they are bound to provide a function for OpenGL function pointer resolution as well.
Unfortunately, it seems as if GDK (the lower-level rendering API of GTK with its class GLContext, https://docs.gtk.org/gdk4/class.GLContext.html) wraps context creation but fails to provide an OpenGL function resolution for extensions.
That's where you were directed to libepoxy (e.g., through https://discourse.gnome.org/t/gtkglarea-issues-context-type-getprocaddress-and-key-events/4187/4 and related discussion as in gtk-rs/gtk3-rs#94).
However, it seems as if we should provide the basic integration with Gtk / Gdk as one of our example integrations in glbinding. As of now, we targeted the cross-platform window toolkits Qt and glfw.

Best regards,
Willy (maintainer of glbinding)

[scheibel]

I just added an example to glbinding that showcases the Cubescape demo with the GTK 3 window toolkit.
It is located at https://github.com/cginternals/glbinding/tree/master/source/examples/cubescape-gtk3-gl.
The main lines to connect GTK and glbinding are as follows (taken from https://github.com/cginternals/glbinding/blob/master/source/examples/cubescape-gtk3-gl/main.cpp#L74 ff.):

gtk_gl_area_set_has_depth_buffer(glarea, true);
gtk_gl_area_make_current(glarea);

// initialize glbinding
glbinding::initialize(glbinding::getProcAddress, false); // only resolve functions that are actually used (lazy)
glbinding::aux::enableGetErrorCallback();

Example image:

Best regards,
Willy

[intractabilis]

I assume that this will not work in GTK4. GTK4 uses OpenGL to render all of its UI. To use GtkGLArea, one must use getProcAddress from the same API that GTK currently uses.

[scheibel]

I added a corresponding GTK 4 Cubescape example in https://github.com/cginternals/glbinding/tree/master/source/examples/cubescape-gtk4-gl.
I needed to rearrange the otherwise identical OpenGL code as the example code isn't the only OpenGL code anymore and, thus, objects for drawing needs to be set active during each render. Otherwise, the glbinding integration is identical to GTK 3 and the other windowing toolkits.

[intractabilis]

This is fantastic. Great job! Thank you.

A small warning. Since version 4.13, GTK has used GLES by default. With GLES, your GTK4 example will show a black screen and will print an infinite line of

glUseProgram generated GL_INVALID_OPERATIONglGetUniformLocation generated GL_INVALID_OPERATIONglGetUniformLocation generated GL_INVALID_OPERATIONglGetUniformLocation generated GL_INVALID_OPERATION...

It works smoothly with GLX and EGL, though.

[scheibel]

When switching from the OpenGL API to the ES variant, there are a number of issues directly waiting (when not using a middleware that counteracts them immediately). One of those is - and that's what happened in your test -, that shader source code is not compatible.

Although glbinding is deliberately designed to only cover the OpenGL API (OpenGL ES is covered by glesbinding), there is a usable common subset of API calls that is actually portable and what allows "OpenGL programs" to run using an OpenGL ES driver. However, the shader issue still needs to get handled.

We prepared such an example with the Cubescape demo that runs on OpenGL 3.3 and OpenGL ES 3.2 drivers (and above). It still needs geometry shaders, so it needs most current OpenGL ES drivers.
Now, I added OpenGL ES variants of our example integrations for GTK 3 and GTK 4 as well.
They're located in https://github.com/cginternals/glbinding/tree/master/source/examples/cubescape-gtk3-gles and https://github.com/cginternals/glbinding/tree/master/source/examples/cubescape-gtk4-gles, respectively.
On my system (Ubuntu 22.04 with X11), I needed to force GTK 3 to use OpenGL ES using an environment variable (GDK_GL=gles), but with GTK 4 the OpenGL ES driver could get selected using plain code.

The main differences between the two demos are as follows:

1. Explicitly select an OpenGL ES 3.2 driver
2. Use a different set of shaders, that mainly differ in the ES-specific preamble:

#version 320 es

precision highp float;
precision highp int;
precision lowp sampler2D;
precision lowp samplerCube;

Best regards,
Willy