Epoxy is a library for handling OpenGL function pointer management for you

Last update: Dec 19, 2022

Related tags

Overview

Epoxy is a library for handling OpenGL function pointer management for you.

It hides the complexity of dlopen(), dlsym(), glXGetProcAddress(), eglGetProcAddress(), etc. from the app developer, with very little knowledge needed on their part. They get to read GL specs and write code using undecorated function names like glCompileShader().

Don't forget to check for your extensions or versions being present before you use them, just like before! We'll tell you what you forgot to check for instead of just segfaulting, though.

Features

Automatically initializes as new GL functions are used.
GL 4.6 core and compatibility context support.
GLES 1/2/3 context support.
Knows about function aliases so (e.g.) glBufferData() can be used with GL_ARB_vertex_buffer_object implementations, along with GL 1.5+ implementations.
EGL, GLX, and WGL support.
Can be mixed with non-epoxy GL usage.

Building

mkdir _build && cd _build
meson
ninja
sudo ninja install

Dependencies for Debian:

meson
libegl1-mesa-dev

Dependencies for macOS (using MacPorts):

pkgconfig
meson

The test suite has additional dependencies depending on the platform. (X11, EGL, a running X Server).

Switching your code to using epoxy

It should be as easy as replacing:

#include <GL/gl.h>
#include <GL/glx.h>
#include <GL/glext.h>

with:

#include <epoxy/gl.h>
#include <epoxy/glx.h>

As long as epoxy's headers appear first, you should be ready to go. Additionally, some new helpers become available, so you don't have to write them:

int epoxy_gl_version() returns the GL version:

12 for GL 1.2
20 for GL 2.0
44 for GL 4.4

bool epoxy_has_gl_extension() returns whether a GL extension is available (GL_ARB_texture_buffer_object, for example).

Note that this is not terribly fast, so keep it out of your hot paths, ok?

Why not use libGLEW?

GLEW has several issues:

Doesn't know about aliases of functions (There are 5 providers of glPointParameterfv(), for example, and you don't want to have to choose which one to call when they're all the same).
Doesn't support OpenGL ES.
Has a hard-to-maintain parser of extension specification text instead of using the old .spec file or the new .xml.
Has significant startup time overhead when glewInit() autodetects the world.
User-visible multithreading support choice for win32.

The motivation for this project came out of previous use of libGLEW in piglit. Other GL dispatch code generation projects had similar failures. Ideally, piglit wants to be able to build a single binary for a test that can run on whatever context or window system it chooses, not based on link time choices.

We had to solve some of GLEW's problems for piglit and solving them meant replacing every single piece of GLEW, so we built piglit-dispatch from scratch. And since we wanted to reuse it in other GL-related projects, this is the result.

Known issues when running on Windows

The automatic per-context symbol resolution for win32 requires that epoxy knows when wglMakeCurrent() is called, because wglGetProcAddress() returns values depend on the context's device and pixel format. If wglMakeCurrent() is called from outside of epoxy (in a way that might change the device or pixel format), then epoxy needs to be notified of the change using the epoxy_handle_external_wglMakeCurrent() function.

The win32 wglMakeCurrent() variants are slower than they should be, because they should be caching the resolved dispatch tables instead of resetting an entire thread-local dispatch table every time.

Comments

Upgrading libepoxy from 1.5.5 to 1.5.7 results in Xorg crashing on boot

Hello,

Basic info:

OS: Manjaro Linux KDE
Kernel: 5.11.18-1-MANJARO
GPU: Radeon R9 380 with AMDGPU drivers

I encountered this issue after an recent Manjaro update which amongst other things updated the libepoxy version from 1.5.5 to 1.5.7 which (as I later found) was the package causing my Xorg to crash on boot. Using the git bisect I managed to find the problematic commit, which is: dbfa4b2

This is the Xorg log after it crashed:

[  5840.928] (WW) Failed to open protocol names file lib/xorg/protocol.txt
[  5840.929] 
X.Org X Server 1.20.11
... a lot more stuff (I can post if needed)
[  5841.290] (II) Initializing extension XFree86-DRI
[  5841.290] (II) Initializing extension DRI2
[  5841.291] (II) AMDGPU(0): Setting screen physical size to 1377 x 285
[  5841.311] (EE) 
[  5841.311] (EE) Backtrace:
[  5841.311] (EE) 0: /usr/lib/Xorg (xorg_backtrace+0x53) [0x55f225222fd3]
[  5841.311] (EE) 1: /usr/lib/Xorg (0x55f2250dc000+0x151df5) [0x55f22522ddf5]
[  5841.311] (EE) 2: /usr/lib/libc.so.6 (0x7f2164329000+0x3cf80) [0x7f2164365f80]
[  5841.311] (EE) 3: /usr/lib/libc.so.6 (gsignal+0x145) [0x7f2164365ef5]
[  5841.311] (EE) 4: /usr/lib/libc.so.6 (abort+0x116) [0x7f216434f862]
[  5841.311] (EE) 5: /usr/lib/libc.so.6 (0x7f2164329000+0x26747) [0x7f216434f747]
[  5841.311] (EE) 6: /usr/lib/libc.so.6 (0x7f2164329000+0x35646) [0x7f216435e646]
[  5841.311] (EE) 7: /usr/lib/xorg/modules/drivers/amdgpu_drv.so (0x7f216485f000+0x8fd3) [0x7f2164867fd3]
[  5841.311] (EE) 8: /usr/lib/xorg/modules/drivers/amdgpu_drv.so (0x7f216485f000+0x933a) [0x7f216486833a]
[  5841.311] (EE) 9: /usr/lib/xorg/modules/drivers/amdgpu_drv.so (0x7f216485f000+0x1534d) [0x7f216487434d]
[  5841.311] (EE) 10: /usr/lib/xorg/modules/drivers/amdgpu_drv.so (0x7f216485f000+0x1746a) [0x7f216487646a]
[  5841.311] (EE) 11: /usr/lib/xorg/modules/drivers/amdgpu_drv.so (0x7f216485f000+0x19127) [0x7f2164878127]
[  5841.311] (EE) 12: /usr/lib/Xorg (MapWindow+0x251) [0x55f22517f871]
[  5841.311] (EE) 13: /usr/lib/Xorg (0x55f2250dc000+0x39619) [0x55f225115619]
[  5841.311] (EE) 14: /usr/lib/libc.so.6 (__libc_start_main+0xd5) [0x7f2164350b25]
[  5841.311] (EE) 15: /usr/lib/Xorg (_start+0x2e) [0x55f2251165de]
[  5841.311] (EE) 
[  5841.311] (EE) 
Fatal server error:
[  5841.311] (EE) Caught signal 6 (Aborted). Server aborting
[  5841.311] (EE) 
[  5841.311] (EE) 
Please consult the The X.Org Foundation support 
         at http://wiki.x.org
 for help. 
[  5841.311] (EE) Please also check the log file at "/home/my_username/.local/share/xorg/Xorg.1.log" for additional information.
[  5841.311] (EE) 
[  5841.327] (EE) Server terminated with error (1). Closing log file.

Link to the Manjaro forum discussing the issue: https://forum.manjaro.org/t/upgrading-libepoxy-from-1-5-5-to-1-5-7-results-in-xorg-crashing-on-boot/66195

opened by Ernest1338 29

meson: add library versioning?
Hi,

I maintain the libepoxy formula in Homebrew. After yesterday's release I decided to give the new meson build system a try, but noticed that the produced dylib is not versioned. This is a bit of a problem, as it breaks our gtk+3 binaries, and all packages that depend on it.

The configure script based install produces:

/usr/local/Cellar/libepoxy/1.4.1/lib/libepoxy.0.dylib /usr/local/Cellar/libepoxy/1.4.1/lib/libepoxy.dylib

with libepoxy.dylib being a symlink to libepoxy.0.dylib

and with the meson installation:

/usr/local/Cellar/libepoxy/1.4.1/lib/libepoxy.dylib

Since the meson docs mention support for versioned libraries, I wondered if it would be useful to use this feature? To me it makes sense that both installation types produce the exact same files.

Best,

Tom
macos build
opened by tschoonj 29
libepoxy crash with AMDGPU-PRO

Hello, I cherry-picked commit 8d58c890646fc1f43bcab702bb9ed6bae94daefe and this caused unbootability of some old proprietary AMD drivers

Can you please enlighten me? Seems that 1.3.1 with that commit is a no-go, but I'm not sure how this can be solved, and if the revert is doable for you
question linux amd binary driver

opened by LocutusOfBorg 28
Allow libopengl.so to be used when GLX_LIB is missing
This maintains compatibility with previous behavior of always using GLX_LIB if it is found. The only change is when there is no GLX_LIB.

Previous behavior when no GLX_LIB:

abort.

New behavior when no GLX_LIB:

Try to load libOpenGL.so as gl_handle (glx_handle remains NULL).

Else, abort.
opened by batesj 20
1.5.0 breaks KWin

Updating libepoxy from 1.4.3 to 1.5.0 breaks KWin compositing. OGL 2 nor OGL 3.1 does work. More info can be found here: https://bugs.kde.org/show_bug.cgi?id=391486 and https://bbs.archlinux.org/viewtopic.php?id=235021.

Is this a regression or intentional change? It has been suggested to report upstream, which is here.
glx nvidia binary driver

opened by jonnyrobbie 20
Appveyor - Windows autobuilds

I created an appveyor yml file for autobuilding libepoxy on Windows and uploading the install artifacts (include, lib, bin) as a zip file to the GitHub releases. Currently the script turns EGL support off. The appveyor yml file would have to be edited to upload to the main repo's GitHub page rather than mine (simply replace 'auth_token', with an encoded GitHub API token for appveyor.
enhancement

opened by tmarrinan 19
Fix some bugs in loading OpenGL/GLX/EGL libraries

Without additional check, even if libOpenGL was loaded, libGL.so will be loaded as well, and used both in gl_handle and glx_handle, so libglvnd libraries will not be used.

The problem is that on Wayland-only system, there will be no libGL, so epoxy_load_gl will fail even if libOpenGL was loaded.

opened by ya-isakov 18
"Couldn't find current GLX or EGL context.\n" exits GNOME Games

When running a game in GNOME Games in some ancient machine, the application quits with this message on stderr: "Couldn't find current GLX or EGL context.". The machine still has a powerful enough GPU (i915 driver) to run gnome-shell and power totem's clutter-gtk video display.

The error message was found in epoxy_get_proc_address().

I would like Games (which uses GtkGLArea) to be able to recover from this error by using a software rendering method, which implies for libepoxy to transmit its errors.
bug linux

opened by Kekun 18
Meson build - Windows
Hello. I am having an issue building with Meson on Windows.

First, when I install Python 3.6 for windows, the executable is python.exe (not python3.exe). When I run meson.py .. . --backend=vs2015 I get an error saying Program python3 found: NO.

I created a symlink from python.exe to python3.exe. This resolved that issue and successfully creates a MSVC solution. However, when building, it has several errors along the lines of:

"C:/Python36/python3.EXE" "python" "C:/projects/libepoxy/src/gen_dispatch.py" <...> C:/Python36/python3.EXE: can't open file 'python': [Errno 2] No such file or directory

It appears as though the gen_dispatch.py is set to be called from python twice, which is what causes the error.
windows build
opened by tmarrinan 18

libepoxy tries to use GLX on Wayland when running in apitrace with libGL

apitrace prints the following message:

glXGetCurrentContext() not found in libGL.so.1: /usr/bin/../lib/apitrace/wrappers/egltrace.so: undefined symbol: glXGetCurrentContext

Here is the backtrace from where libepoxy calls exit():

Breakpoint 1, 0x00007ffff6faccd0 in _exit () from /usr/lib/libc.so.6
(gdb) bt
#0  0x00007ffff6faccd0 in _exit () from /usr/lib/libc.so.6
#1  0x00007ffff6f29f3b in __run_exit_handlers () from /usr/lib/libc.so.6
#2  0x00007ffff6f29fd5 in exit () from /usr/lib/libc.so.6
#3  0x00007ffff72f051a in do_dlsym (handle=<optimized out>, lib_name=0x7ffff7344b20 "libGL.so.1", name=0x7ffff7362b77 <entrypoint_strings+1143> "glXGetCurrentContext", exit_on_fail=<optimized out>)
    at dispatch_common.c:262
#4  0x00007ffff73413c6 in glx_provider_resolver (entrypoints=0x7fffffffda2c, providers=0x7fffffffda30, name=0x7ffff7362b77 <entrypoint_strings+1143> "glXGetCurrentContext") at glx_generated_dispatch.c:562
#5  glx_single_resolver (provider=provider@entry=GLX_10, entrypoint_offset=entrypoint_offset@entry=1143) at glx_generated_dispatch.c:590
#6  0x00007ffff7342c26 in epoxy_glXGetCurrentContext_resolver () at glx_generated_dispatch.c:903
#7  epoxy_glXGetCurrentContext_global_rewrite_ptr () at glx_generated_dispatch.c:1425
#8  0x00007ffff72f0553 in epoxy_current_context_is_glx () at dispatch_common.c:412
#9  0x00007ffff72f060d in epoxy_is_desktop_gl () at dispatch_common.c:282
#10 0x00007ffff72f6635 in gl_provider_resolver (name=0x7ffff7354ad8 <entrypoint_strings+16120> "glGenTextures", providers=0x7ffff734ef78 <providers>, entrypoints=0x7ffff734ef72 <entrypoints>)
    at gl_generated_dispatch.c:7319
#11 0x00007ffff73240b9 in epoxy_glGenTextures_resolver () at gl_generated_dispatch.c:18408
#12 epoxy_glGenTextures_global_rewrite_ptr (n=1, textures=0x7fffffffdb54) at gl_generated_dispatch.c:46117
#13 0x00000000004009c0 in main ()

I originally thought this was an apitrace bug, see https://github.com/apitrace/apitrace/issues/380

opened by linkmauve 17

macOS epoxy_has_gl_extension() only working with legacy OpenGL

I've been playing with trying to understand why VICE Gtk3 performs so bad on macOS vs linux and Windows.

I discovered that VICE works great if Gdk doesn't ask for OpenGL 3.2 or 4.1, and gets the legacy renderer instead. Host CPU performance goes from about 75% to 45%.

When running with gl 2.1, epoxy_has_gl_extension() reports support for GL_ARB_texture_non_power_of_two, GL_ARB_texture_rectangle and GL_EXT_framebuffer_blit. When running with gl 3.2 or 4.1, epoxy_has_gl_extension() does not detect support for these extensions.

I found that if I force the detection result for these extensions in Gdk, VICE performance is also great with the 3.2 and 4.1 renderers. So I assume there must be something wrong with epoxy_has_gl_extension() in this case. In fact, I just have to force detection of GL_EXT_framebuffer_blit to get the result i'm looking for

I intend to try to understand and fix this, but I thought i'd open an issue to track it.

opened by dqh-au 15

undefined glXGetCurrentContext on EGL tracing

How I understand the situation is following:

GTK wants to render context.
libepoxy starts query for symbol glXGetCurrentContext
because the GL library points to EGL, the symbol is missing
apitrace crashes due to the GTK app (epoxy) cannot find the symbol

A possible solution would be a variable to disable GLX or EGL at runtime.

Additional idea: Change order to prefer EGL in epoxy (which makes sense because EGL is more widespread these days).

$ apitrace trace -a egl gtk4-demo
apitrace: loaded into /usr/bin/apitrace
apitrace: unloaded from /usr/bin/apitrace
apitrace: loaded into /usr/bin/gtk4-demo
** Message: 02:06:00.252: For syntax highlighting, install the “highlight” program
apitrace: redirecting dlopen("libEGL.so.1", 0x1) from /lib/x86_64-linux-gnu/libepoxy.so.0
apitrace: tracing to /home/projects/collabora/mesa/gtk4-demo.trace
apitrace: warning: eglChooseConfig: unknown key 0x3339, interpreting value as int
apitrace: warning: eglChooseConfig: unknown key 0x3339, interpreting value as int
apitrace: redirecting dlopen("libGL.so.1", 0x1) from /lib/x86_64-linux-gnu/libepoxy.so.0
apitrace: attempting to read configuration file: /home/okias/.config/apitrace/gltrace.conf
apitrace: using configuration file: /home/okias/.config/apitrace/gltrace.conf
apitrace: config GL_VENDOR = 
apitrace: config GL_VERSION = 4.5
apitrace: config GL_EXTENSIONS = 
apitrace: config GL_NUM_EXTENSIONS = 0
apitrace: config GL_RENDERER = 
apitrace: config GL_SHADING_LANGUAGE_VERSION = 4.50
apitrace: config GL_MAX_TEXTURE_SIZE = 0
apitrace: config GL_MAJOR_VERSION = 4
apitrace: config GL_MINOR_VERSION = 5
apitrace: config GL_CONTEXT_PROFILE_MASK = 0x0
apitrace: config GL_CONTEXT_PROFILE_MASK = 0x0
apitrace: config GL_UNIFORM_BUFFER_OFFSET_ALIGNMENT = 32
apitrace: config GL_TEXTURE_BUFFER_OFFSET_ALIGNMENT = 16
apitrace: config GL_STORAGE_BUFFER_OFFSET_ALIGNMENT = 4
glXGetCurrentContext() not found: /usr/bin/../lib/x86_64-linux-gnu/apitrace/wrappers/egltrace.so: undefined symbol: glXGetCurrentContext
apitrace: warning: caught signal 6
apitrace: flushing trace
/usr/bin/../lib/x86_64-linux-gnu/apitrace/wrappers/egltrace.so+0x226300
/lib/x86_64-linux-gnu/libc.so.6+0x3bf8f: ./signal/../sysdeps/unix/sysv/linux/x86_64/libc_sigaction.c:0
/lib/x86_64-linux-gnu/libc.so.6: __pthread_kill_implementation+0x8accc: ./nptl/pthread_kill.c:44
/lib/x86_64-linux-gnu/libc.so.6: __GI_raise+0x11: ../sysdeps/posix/raise.c:26
/lib/x86_64-linux-gnu/libc.so.6: __GI_abort+0xd2: ./stdlib/abort.c:79
/lib/x86_64-linux-gnu/libepoxy.so.0: do_dlsym+0xc0fb0: ../src/dispatch_common.c:343
/lib/x86_64-linux-gnu/libepoxy.so.0: epoxy_glXGetCurrentContext_resolver+0xbecee: src/glx_generated_dispatch.c:3736
/lib/x86_64-linux-gnu/libepoxy.so.0: epoxy_glXGetCurrentContext_global_rewrite_ptr+0xbecee: src/glx_generated_dispatch.c:4270
/lib/x86_64-linux-gnu/libepoxy.so.0: epoxy_get_bootstrap_proc_address+0xc185d: ../src/dispatch_common.c:813
/lib/x86_64-linux-gnu/libepoxy.so.0: gl_single_resolver+0x64332: src/gl_generated_dispatch.c:75810
/lib/x86_64-linux-gnu/libepoxy.so.0: epoxy_glGetIntegerv_resolver+0x70ffe: src/gl_generated_dispatch.c:87733
/lib/x86_64-linux-gnu/libepoxy.so.0: epoxy_glGetIntegerv_global_rewrite_ptr+0x70ffe: src/gl_generated_dispatch.c:115489
/lib/x86_64-linux-gnu/libepoxy.so.0: epoxy_internal_has_gl_extension+0xc128a: ../src/dispatch_common.c:530
/lib/x86_64-linux-gnu/libepoxy.so.0: epoxy_internal_has_gl_extension+0xc128a: ../src/dispatch_common.c:519
/lib/x86_64-linux-gnu/libgtk-4.so.1: gdk_gl_context_make_current+0x21a
/lib/x86_64-linux-gnu/libgtk-4.so.1+0x4b7a23
/lib/x86_64-linux-gnu/libgtk-4.so.1+0x4ac48f
/lib/x86_64-linux-gnu/libgtk-4.so.1: gsk_renderer_realize+0x11d
/lib/x86_64-linux-gnu/libgtk-4.so.1: gsk_renderer_new_for_surface+0x9c
/lib/x86_64-linux-gnu/libgtk-4.so.1+0x31e6b7
/lib/x86_64-linux-gnu/libgtk-4.so.1+0xd3680
/lib/x86_64-linux-gnu/libgobject-2.0.so.0: g_closure_invoke+0x15f
/lib/x86_64-linux-gnu/libgobject-2.0.so.0+0x28d2c
/lib/x86_64-linux-gnu/libgobject-2.0.so.0: g_signal_emit_valist+0xf34
/lib/x86_64-linux-gnu/libgobject-2.0.so.0: g_signal_emit+0x8e
/lib/x86_64-linux-gnu/libgtk-4.so.1: gtk_widget_realize+0x6f
/lib/x86_64-linux-gnu/libgtk-4.so.1+0x323851
/lib/x86_64-linux-gnu/libgobject-2.0.so.0+0x165a8
/lib/x86_64-linux-gnu/libgobject-2.0.so.0: g_signal_emit_valist+0xefe
/lib/x86_64-linux-gnu/libgobject-2.0.so.0: g_signal_emit+0x8e
/lib/x86_64-linux-gnu/libgtk-4.so.1: gtk_widget_show+0xa0
/lib/x86_64-linux-gnu/libgtk-4.so.1: gtk_window_present_with_time+0xb4
gtk4-demo+0x6cf77
/lib/x86_64-linux-gnu/libgio-2.0.so.0+0x81b66
/lib/x86_64-linux-gnu/libgobject-2.0.so.0: g_closure_invoke+0x15f
/lib/x86_64-linux-gnu/libgobject-2.0.so.0+0x29075
/lib/x86_64-linux-gnu/libgobject-2.0.so.0: g_signal_emit_valist+0x76c
/lib/x86_64-linux-gnu/libgobject-2.0.so.0: g_signal_emit+0x8e
/lib/x86_64-linux-gnu/libgio-2.0.so.0+0xdafd2
/lib/x86_64-linux-gnu/libgio-2.0.so.0+0xdd309
/lib/x86_64-linux-gnu/libgio-2.0.so.0: g_application_run+0x145
gtk4-demo: main+0x204
/lib/x86_64-linux-gnu/libc.so.6: __libc_start_call_main+0x27189: ../sysdeps/nptl/libc_start_call_main.h:58
/lib/x86_64-linux-gnu/libc.so.6: __libc_start_main_impl+0x84: ../csu/libc-start.c:381
gtk4-demo: _start+0x20
?
apitrace: info: taking default action for signal 6

opened by okias 0

How better to implement strndup for MacOS versions that do not have it? (needed for EGL)
Two source file related to EGL use strndup which is missing on MacOS X < 10.7 – egl_has_extension_nocontext.c and egl_epoxy_api.c.

In Macports we can use legacysupport PortGroup, which provides needed definition: https://github.com/macports/macports-legacy-support/blob/master/include/string.h

I guess it can be borrowed and included either directly in those 2 files or in a header common to them. Condition can be something like:

#ifdef __APPLE__ #include <AvailabilityMacros.h> #if __MAC_OS_X_VERSION_MIN_REQUIRED < 1070 [put definition here] #endif #endif
opened by barracuda156 0

Build failure on dispatch_egl: error: unknown type name 'EGLDisplay'

Compilation fails with Egl option enabled on 10.6.8:

../anholt-libepoxy-70a20c6/src/dispatch_egl.c: In function 'epoxy_conservative_egl_version':
../anholt-libepoxy-70a20c6/src/dispatch_egl.c:33:5: error: unknown type name 'EGLDisplay'; did you mean 'Display'?
   33 |     EGLDisplay dpy = eglGetCurrentDisplay();
      |     ^~~~~~~~~~
      |     Display
../anholt-libepoxy-70a20c6/src/dispatch_egl.c:33:22: error: implicit declaration of function 'eglGetCurrentDisplay'; did you mean 'glXGetCurrentDisplay'? [-Werror=implicit-function-declaration]
   33 |     EGLDisplay dpy = eglGetCurrentDisplay();
      |                      ^~~~~~~~~~~~~~~~~~~~
      |                      glXGetCurrentDisplay
../anholt-libepoxy-70a20c6/src/dispatch_egl.c:33:22: warning: nested extern declaration of 'eglGetCurrentDisplay' [-Wnested-externs]
../anholt-libepoxy-70a20c6/src/dispatch_egl.c:38:12: error: implicit declaration of function 'epoxy_egl_version'; did you mean 'epoxy_gl_version'? [-Werror=implicit-function-declaration]
   38 |     return epoxy_egl_version(dpy);
      |            ^~~~~~~~~~~~~~~~~
      |            epoxy_gl_version
../anholt-libepoxy-70a20c6/src/dispatch_egl.c:38:12: warning: nested extern declaration of 'epoxy_egl_version' [-Wnested-externs]
../anholt-libepoxy-70a20c6/src/dispatch_egl.c: At top level:
../anholt-libepoxy-70a20c6/src/dispatch_egl.c:61:19: error: unknown type name 'EGLDisplay'; did you mean 'Display'?
   61 | epoxy_egl_version(EGLDisplay dpy)
      |                   ^~~~~~~~~~
      |                   Display
../anholt-libepoxy-70a20c6/src/dispatch_egl.c: In function 'epoxy_conservative_has_egl_extension':
../anholt-libepoxy-70a20c6/src/dispatch_egl.c:79:12: error: implicit declaration of function 'epoxy_has_egl_extension'; did you mean 'epoxy_has_gl_extension'? [-Werror=implicit-function-declaration]
   79 |     return epoxy_has_egl_extension(eglGetCurrentDisplay(), ext);
      |            ^~~~~~~~~~~~~~~~~~~~~~~
      |            epoxy_has_gl_extension
../anholt-libepoxy-70a20c6/src/dispatch_egl.c:79:12: warning: nested extern declaration of 'epoxy_has_egl_extension' [-Wnested-externs]
../anholt-libepoxy-70a20c6/src/dispatch_egl.c: At top level:
../anholt-libepoxy-70a20c6/src/dispatch_egl.c:94:25: error: unknown type name 'EGLDisplay'; did you mean 'Display'?
   94 | epoxy_has_egl_extension(EGLDisplay dpy, const char *ext)
      |                         ^~~~~~~~~~
      |                         Display
../anholt-libepoxy-70a20c6/src/dispatch_egl.c:107:1: warning: no previous prototype for 'epoxy_has_egl' [-Wmissing-prototypes]
  107 | epoxy_has_egl(void)
      | ^~~~~~~~~~~~~
cc1: some warnings being treated as errors

P. S. mesa @19.0.8_1+osmesa+python27 (with Egl support enabled), gcc12 @12.2.0.

opened by barracuda156 3

glPushDebugGroupKHR jumping at the wrong offset into the dispatch table

Epoxy reports that the GL_KHR_debug extension is supported, but when calling glPushDebugGroupKHR it actually jumps at the dispatch entry for glProgramUniformMatrix2x4fvEXT, which happens to ba unavailable on my system, and then the application crashes.

769         glPushDebugGroupKHR (GL_DEBUG_SOURCE_APPLICATION, 0, -1, message);
(gdb) s
epoxy_glPushDebugGroupKHR_dispatch_table_thunk (source=33354, id=0, length=-1, message=0x7ffdc2e189cb <__func__.0+1915> "Building command queue") at src/gl_generated_dispatch.c:51142
51142      0, // glProgramUniformMatrix2x4fvEXT
(gdb) n
Thread 1 received signal SIGSEGV, Segmentation fault.
0x0000000000000000 in ?? ()
(gdb)

See https://gitlab.gnome.org/GNOME/gtk/-/issues/5128

AMD driver
Windows 10 21H2
MSYS2

opened by lb90 3

missing WGL_ARB_extensions_string
I am getting

Implementation unexpectedly missing WGL_ARB_extensions_string. Probably a libepoxy bug.

from https://github.com/anholt/libepoxy/blob/1.5.10/src/dispatch_wgl.c#L54-L60.

Apparently, wglGetProcAddress("wglGetExtensionsStringARB") returns NULL. Any idea what might be wrong?
opened by christianrauch 0

Releases(1.5.10)

1.5.10(Mar 18, 2022)
Changes since 1.5.9

Fix for building with MSVC on non-English locale [Seungha Yang]

Fix build on Android [Caolán McNamara]

Add the right include paths for EGL and X11 headers [Alex Richardson]

Source code(tar.gz)
Source code(zip)
1.5.9(Aug 14, 2021)
Changes since 1.5.8

Allow libopengl.so to be used when GLX_LIB is missing [#257, John Bates]

Source code(tar.gz)
Source code(zip)
libepoxy-1.5.9.tar.xz(216.72 KB)
1.5.8(May 21, 2021)
Changes since 1.5.7

Revert changes from PR #238 / #229

Fixes regressions: #240, #252, #253

Source code(tar.gz)
Source code(zip)
libepoxy-1.5.8.tar.xz(216.62 KB)
1.5.7(Apr 30, 2021)
Changes since Epoxy 1.5.6

Remove type redefinition [#249]

Source code(tar.gz)
Source code(zip)
libepoxy-1.5.7.tar.xz(216.67 KB)
1.5.6(Apr 30, 2021)
Changes since 1.5.5

Fix issue with loading OpenGL/GLX/EGL libraries [#238, Yaroslav Isakov]

Expose dependency variables in pkg-config file [#231, Xavier Claessens]

Support Win64 pointer-sized types [#246]

Close output objects when generating files [#242, Aleksandr]

Source code(tar.gz)
Source code(zip)
libepoxy-1.5.6.tar.xz(216.58 KB)
1.5.5(Dec 22, 2020)
Changes since 1.5.4

Remove Python 2 support [#213]

Remove Autotools support [#212]

Use EGL_NO_X11 to disable X11 headers [#216]

Use call convention for mock function [crziter, #220]

Return correct version of GLSL on GLES2 [Eric Anholt, #223]

Rely on Meson's darwin_versions option [#225]

Source code(tar.gz)
Source code(zip)
libepoxy-1.5.5.tar.xz(218.44 KB)
1.5.4(Nov 25, 2019)
Changes since 1.5.3:

Don't build GLX tests if X11 support is disabled [Nirbheek Chauhan]

Add unit tests for epoxy_gl_version() [Eric Anholt]

Reduce the size of the binary by reusing static strings [Eric Anholt]

Fix build on Solaris [Alan Coopersmith]

Update the GL registries [Guchetan Singh]

Source code(tar.gz)
Source code(zip)
libepoxy-1.5.4.tar.xz(221.85 KB)
1.5.3(Oct 4, 2018)
Changes since 1.5.2:

Disable EGL on macOS

Fix build on macOS [#176, Emmanuele Bassi]

Add macOS tests

Fix build with uClibc [#181, Emmanuele Bassi]

Fix GLES3 symbol lookup [Adam Jackson]

Fix conditional compilation [#184, Zhao Zhili]

Require Meson 0.47

Fix Autotools build with EGL-X11 support [#188, Emmanuele Bassi]

Source code(tar.gz)
Source code(zip)
libepoxy-1.5.3.tar.xz(215.37 KB)
libepoxy-shared-x64.zip(2.22 MB)
libepoxy-shared-x86.zip(1.82 MB)
1.5.2(May 19, 2018)
Changes since 1.5.1:

Fix the detection of the -z,relro linker flag

Query the EGL context version when bootstrapping on GLES [Adam Jackson]

Avoid inadvertedly loading libraries when probing for them [Adam Jackson]

Issue #169: Fix build on FreeBSD [Ting-Wei Lan]

Consistently use abort() instead of exit() for internal state checks

Issue #171: Fix a performance regression in the global function pointer trampolines introduced by using -Bsymbolic-functions

Improve performance when using GL function pointers like glAlphaFunc [Adam Jackson]

Source code(tar.gz)
Source code(zip)
libepoxy-1.5.2.tar.xz(791.05 KB)
libepoxy-shared-x64.zip(2.22 MB)
libepoxy-shared-x86.zip(1.82 MB)
1.5.1(Apr 25, 2018)
Changes since 1.5.0:

Do no add pkg-config dependencies on gl on systems that do not use pkg-config, like macOS and Windows [Tom Schoonjans, #156]

Generalise checks for dlvsym [Ross Burton, #158]

Add an option for disabling building the test suite [Ross Burton]

Typo fixes in the comments and documentation [luz.paz, #159]

Simplify the Meson configuration logic for EGL and GLX [Eric Engestrom, #162]

Use assert when no context is found [Adam Jackson, #166]

Remove a test superceded by GLVND [#165]

Avoid Meson warnings when testing for linker arguments

Source code(tar.gz)
Source code(zip)
libepoxy-1.5.1.tar.xz(788.82 KB)
1.5.0(Feb 28, 2018)
Changes from Epoxy 1.4.3

Bump the Meson dependency to 0.44.1

Include Xlib.h in the tests that use X11 API

Update the GL registry to OpenGL 4.6

Add gl and egl private dependencies in the pkg-config file

Allow building Epoxy without X11 support

Rename the Meson configuration options to be more idiomatic

New API:

epoxy_set_resolver_failure_handler()

epoxy_glsl_version()

epoxy_extension_in_string()

Issues fixed

#128 - Fix macOS linker flags [Tom Schoonjans]

#129 - Use GLVND if available [Adam Jackson]

#134 - Add fallback definition for EGL_CAST [Daniel Stone]

#133 - Try even harder to not load GLX [Adam Jackson]

#138 - Fix the libOpenGL soname [Adam Jackson]

#137 - Update differences with GLEW [Nigel Stewart]

#131 - Add epoxy_set_resolver_failure_handler() [Adam Jackson]

#140 - Fix pointer mismatch on Windows 10 [danem]

#141 - Define visibility flags for static builds [Dylan Baker]

#136 - Expose epoxy_extension_in_string() [Lyude Paul]

#151 - Use correct guard for Android builds [Robert Bragg]

#154 - Fix dlwrap for glvnd [Adam Jackson]

#155 - Respect DLOPEN_LIBS [Michał Górny]

#143 - Fix printf family usage [Ikey Doherty]

#152 - Do not use OPENGL_LIB on Android

#145 - Add epoxy_glsl_version()

Source code(tar.gz)
Source code(zip)
libepoxy-1.5.0.tar.xz(788.96 KB)
libepoxy-shared-x64.zip(2.14 MB)
libepoxy-shared-x86.zip(1.76 MB)
1.4.3(Jun 6, 2017)
This is a new stable release.

Changes from 1.4.2

Require Meson 0.39.1; the previous release already had an implicit requirement on this version (#121)

Allow disabling EGL support when building Epoxy (#123, Thomas Petazzoni)

Add support for building on Haiku (#124, Joseph Hill)

Update EGL registry from Khronos (#126, Daniel Stone)

Source code(tar.gz)
Source code(zip)
libepoxy-1.4.3.tar.xz(765.25 KB)
libepoxy-shared-x64.zip(2.09 MB)
libepoxy-shared-x86.zip(1.72 MB)
1.4.2(Apr 30, 2017)
This is a new stable release.

Changes from 1.4.1:

Add C++ guards around generated headers (#106)

Add z,relro and z,now to the GCC linker flags

Add explicit version flags for macOS builds (#108)

Add missing visibility compiler flags (#111)

Prefer using pkg-config files to find GLES (#110)

Fix build on MSVC 2013 when using the inline keyword (#112)

Fix dlwrap on aarch64 (#114)

Require Meson ≥ 0.38.1

Allow building Epoxy as a Meson sub-project (#115)

Avoid crashes when running Epoxy on X servers without GLX (#118)

Source code(tar.gz)
Source code(zip)
libepoxy-1.4.2.tar.xz(763.12 KB)
libepoxy-shared-x64.zip(2.09 MB)
libepoxy-shared-x86.zip(1.72 MB)
1.4.1(Mar 2, 2017)
This is a new stable release.

Changes from 1.4.0:

Find the appropriate version of the Python interpreter when building (#100)

Ensure that the dispatch generation script works with Python 2.x and 3.x

Ensure that Epoxy builds correctly under Windows (including CI — see: #95 and #104)

Fix location of the m4 macros in the autotools build (#58)

Source code(tar.gz)
Source code(zip)
libepoxy-1.4.1.tar.xz(759.98 KB)
libepoxy-shared-x64.zip(2.09 MB)
libepoxy-shared-x86.zip(1.71 MB)
v1.4(Feb 6, 2017)
This is a new stable release.

Major changes for 1.4 are:

Epoxy can now build with MSVC versions prior to 2013; we still recommend using a recent, C99-compatible compiler, like MSVC 2015 [Chun-wei Fan]

When used under X11, Epoxy now attempts to handle the cases where the GLX extension is not built or not available [Yaron Cohen-Tal]

GLX can now be enabled and disabled at configuration time; this allows building Epoxy with GLX on macOS, and allows building Epoxy without GLX on embedded platforms

Epoxy now exposes API that lets dependent projects safely check if platform API like GLX and EGL is available at run time

EGL support has been improved on Windows, and made more resilient on other platforms [Yaron Cohen-Tal, Adam Jackson]

Epoxy supports building with the Meson build system, which has Ninja, Visual Studio, and XCode backends

Epoxy can generate its API reference using Doxygen (currently only available on Meson builds)

The GL registry has been updated with the latest version of the API references provided by Khronos; Epoxy now supports the API introduced by OpenGL 4.5

Source code(tar.gz)
Source code(zip)
libepoxy-1.4.0.tar.xz(749.54 KB)
v1.3.1(Jul 16, 2015)

This is a brown-paper-bag fix to unexport another private symbol that we'd leaked, noticed when I went diffing the exported symbols between v1.2 and v1.3 for the debian build.
Source code(tar.gz)
Source code(zip)
libepoxy-1.3.1.tar.bz2(800.89 KB)
v1.3(Jul 16, 2015)

The big change in this version is MSVC 2013 support. Sadly, mingw is unable to build MSVC-compatible dlls, as far as I've been able to figure out, so I've merged fanc999's patches for MSVC 2013 support.

Another big change is that OSX drops GLX support. I had had near-universal complaints about including it, and its seems like X on OSX is really not used these days (The lack of activity on its X server makes that pretty obvious).

Also included are the usual updates to the registry, fixes for a nonconformant GL implementation, some library size reductions, and reproducible builds.
Source code(tar.gz)
Source code(zip)
libepoxy-1.3.tar.bz2(800.05 KB)
v1.2(May 14, 2014)

This is a bugfix and feature release. On the feature side of things, it brings in an updated registry with support for GLES 3.1 and EGL 1.5, along with miscellaneous other extensions, and many more aliases for GLES functions. On the bugfix side, it should be much more portable to non-Mesa drivers (nvidia binary in particular) and systems with mixed Mesa and non-Mesa drivers, and actually install the wgl headers in the windows build (oops!).

This release got delayed because I kept saying "I'm going to fix making a built library that's usable with MSVC", and never quite managing to. That's still my primary goal for the next release, but it was long past time to get something out the door.
Source code(tar.gz)
Source code(zip)
epoxy-1.2-win32.zip(3.25 MB)
v1.1(Feb 6, 2014)

This is a bugfix release. The registry is updated, which includes fixes to some enums from Khronos. Build fixes are included for 32-bit linux, --as-needed, and apps that link without pulling in libdl themselves. Also, GLES1/2 apps on systems without GLX are fixed.

Thanks go to Matt Turner for the --as-needed fix, to Daniel Kurtz for testing the library on a very different system from mine and filing bugs, and to Julien Cristau for reviewing the v1.0 debian package.
Source code(tar.gz)
Source code(zip)
epoxy-1.1-win32.zip(2.37 MB)
v1.0(Jan 29, 2014)

Here's the initial release of libepoxy, tested on Linux to not regress the piglit GL testsuite when converting it to using epoxy, and tested a few revisions ago on OS X as well. Win32/64 testing has been limited to the (very small) tests in the epoxy tree.

The plan is that the ABI is stable at this point and won't need SO version bumps. The only known upcoming ABI change is GL_ALL_ATTRIB_BITS changing based on Khronos's bug resolution (but then, this is an issue that all users of GL face, if so). There are basically no consumers of this API, and the change will be in a serious corner case where the GL specs contradict each other, so I expect this to affect exactly nobody except for piglit users.

As far as other known issues, this release paves the way for a maximum-performance win32 implementation by using function pointers, but doesn't yet implement it. mingw-built (and wine32-tested) binaries will be attached to the release, but I don't actually do any development on windows. Hopefully someone interested in the platform can take this on.
Source code(tar.gz)
Source code(zip)
epoxy-1.0-win32.zip(2.37 MB)