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

Related tags

Graphics libepoxy

Ubuntu macOS MSVC Build MSYS2 Build License: MIT

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.


  • 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.


mkdir _build && cd _build
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>


#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.

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

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


    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?

    meson: add library versioning?


    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:


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

    and with the meson installation:


    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.



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

    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

    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

    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

    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.

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

    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

    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

    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

    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

    undefined glXGetCurrentContext on EGL tracing

    How I understand the situation is following:

    1. GTK wants to render context.
    2. libepoxy starts query for symbol glXGetCurrentContext
    3. because the GL library points to EGL, the symbol is missing
    4. 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
    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
    /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: gsk_renderer_realize+0x11d
    /lib/x86_64-linux-gnu/libgtk-4.so.1: gsk_renderer_new_for_surface+0x9c
    /lib/x86_64-linux-gnu/libgobject-2.0.so.0: g_closure_invoke+0x15f
    /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/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
    /lib/x86_64-linux-gnu/libgobject-2.0.so.0: g_closure_invoke+0x15f
    /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: 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)

    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>
    [put definition here]
    opened by barracuda156 0
  • Build failure on dispatch_egl: error: unknown type name 'EGLDisplay'

    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

    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 ?? ()

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

    • AMD driver
    • Windows 10 21H2
    • MSYS2
    opened by lb90 3
  • missing WGL_ARB_extensions_string

    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
  • 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)

  • 1.5.8(May 21, 2021)

  • 1.5.7(Apr 30, 2021)

  • 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)

  • 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)

  • 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)

  • 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)

  • 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)
Eric Anholt
Eric Anholt
A multi-platform library for OpenGL, OpenGL ES, Vulkan, window and input

GLFW Introduction GLFW is an Open Source, multi-platform library for OpenGL, OpenGL ES and Vulkan application development. It provides a simple, platf

GLFW 10k Jan 1, 2023
A legacy OpenGL simulator for OpenGL 4.4, written in C++.

the-ancient-tri A legacy OpenGL simulator for OpenGL 4.4, written in C++. Why? My Uni forces us to use legacy OpenGL (eww!), and I didn't want to lear

Mohammad Issawi 4 Feb 10, 2022
OpenGL Object Loading can load virtually every 3d.obj file you can find on the internet, without using another object loading library

OpenGL Object Loading can load virtually every 3d.obj file you can find on the internet, without using another object loading library (assimp for example). The program can load Object with 12M+ triangles and more

Phan Sang 15 Dec 18, 2022
Low Level Graphics Library (LLGL) is a thin abstraction layer for the modern graphics APIs OpenGL, Direct3D, Vulkan, and Metal

Low Level Graphics Library (LLGL) Documentation NOTE: This repository receives bug fixes only, but no major updates. Pull requests may still be accept

Lukas Hermanns 1.5k Jan 8, 2023
Antialiased 2D vector drawing library on top of OpenGL for UI and visualizations.

This project is not actively maintained. NanoVG NanoVG is small antialiased vector graphics rendering library for OpenGL. It has lean API modeled afte

Mikko Mononen 4.6k Jan 2, 2023
3D engine from scratch (without OpenGL or any other 3D graphics library)

Simple 3d engine based on SFML library. I tried to make this engine powerful and easy to understand.

Vectozavr 64 Dec 10, 2022
Yet another Chip-8 interpreter, this time written in C++ using GLFW and OpenGL as its graphics library 💻

Yet another Chip-8 interpreter, but this time with a beautiful interface ??

Akshit Garg 30 Dec 14, 2022
A C++ port of Wave Function Collapse Tiling

Wave Function Collapse in C++ This is a C++ port of https://github.com/mxgmn/WaveFunctionCollapse. All sample images come from https://github.com/mxgm

Emil Ernerfeldt 297 Dec 26, 2022
Single-header single-function C/C++ immediate-mode camera for your graphics demos

Single-header single-function C/C++ immediate-mode camera for your graphics demos

Nicolas Guillemot 106 Oct 20, 2022
A minimal Direct3D 12 example that draws an animated triangle, written entirely in C-style C++, and all taking place inside a single function.

A minimal Direct3D 12 example that draws an animated triangle, written entirely in C-style C++, and all taking place inside a single function.

Taoufik Rida Bouftass 7 May 3, 2022
RGL - 3D visualization device system for R using OpenGL

RGL - 3D visualization device system for R using OpenGL INTRODUCTION The RGL package is a visualization device system for R, using OpenGL or WebGL as

null 68 Dec 27, 2022
OpenGL Demo: Simulating Ocean Waves with FFT

OceanFFT Realistic ocean wave simulation, primarily based on J. Tessendorf's paper, using OpenGL compute shaders. Checkout the demo video here. In the

Achal Pandey 70 Dec 27, 2022
OBS Linux Vulkan/OpenGL game capture

OBS Linux Vulkan/OpenGL game capture OBS plugin for Vulkan/OpenGL game capture on Linux. Requires OBS with EGL support (currently unreleased, you need

David Rosca 290 Jan 1, 2023
NodeEditor basiced on Qt and OpenGL/CV

Vapour 基于Qt的轻量级的节点式几何建模工具与shader材质生成工具 可能加入图像处理(合成)的功能 日志: 2021-5-17: 完成背景绘制,右键菜单,节点连线,节点删除,初步拓扑排序 (细节)连线位于节点层级之下,使用lambda处理右键菜单slot,节点创建生成在鼠标位置处 2021

Cuimi 17 Dec 19, 2022
C Wavefront OBJ loader for OpenGL

OBJ GL Loader v2 Quite fast .OBJ loader written in C How to use it Put objgl2.c and objgl2.h files in Your project and include them. To put it simply:

null 9 Oct 14, 2022
Orbit is a multiplatform-focus graphical engine build on top of OpenGl, ImGui

Orbit Engine Orbit is a multiplatform-focus graphical engine build on top of OpenGl, ImGui and more... The development of the engine is documented via

Madsycode 11 Jul 3, 2021
Axel Gneiting 1.5k Dec 31, 2022
A 2d Graphing Calculator using OpenGL

glGraph A 2d Graphing Calculator using Modern OpenGL Demo glGraph.mp4 Information This has only been tested on Fedora 34, it should work on other OS's

Nathan Medros 16 Nov 26, 2022
Tetris written with C++ and OpenGL.

Tetrec This is yet another Tetris game, which is in 3D, written using C++ and OpenGL 2.1, aiming at being lightweight towards not-so-beefy computers (

Lê Duy Quang 14 Jan 17, 2022