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

Related tags

Game libepoxy
Overview

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.

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

    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?

    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

    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.

    enhancement 
    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 ([email protected]=GLX_10, [email protected]=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
  • 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>
    
    #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'

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

    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
  • not compiling under musl

    not compiling under musl

    [16/23] cc -Isubprojects/libepoxy-1.5.9/src/libepoxy.so.0.0.0.p -Isubprojects/libepoxy-1.5.9/src -I../../home/mangix/devstuff/wrapdb/subprojects/libepoxy-1.5
    ninja: job failed: cc -Isubprojects/libepoxy-1.5.9/src/libepoxy.so.0.0.0.p -Isubprojects/libepoxy-1.5.9/src -I../../home/mangix/devstuff/wrapdb/subprojects/lIn file included from ^[[01m^[[K../../home/mangix/devstuff/wrapdb/subprojects/libepoxy-1.5.9/src/dispatch_common.h:46^[[m^[[K,                                                from ^[[01m^[[Ksubprojects/libepoxy-1.5.9/src/egl_generated_dispatch.c:11^[[m^[[K:
    ^[[01m^[[K../../home/mangix/devstuff/wrapdb/subprojects/libepoxy-1.5.9/include/epoxy/glx.h:36:10:^[[m^[[K ^[[01;31m^[[Kfatal error: ^[[m^[[KX11/Xlib.h: No su   36 | #include ^[[01;31m^[[K<X11/Xlib.h>^[[m^[[K                                                                                                                 |          ^[[01;31m^[[K^~~~~~~~~~~~^[[m^[[K
    compilation terminated.
    ninja: job failed: cc -Isubprojects/libepoxy-1.5.9/src/libepoxy.so.0.0.0.p -Isubprojects/libepoxy-1.5.9/src -I../../home/mangix/devstuff/wrapdb/subprojects/lIn file included from ^[[01m^[[K../../home/mangix/devstuff/wrapdb/subprojects/libepoxy-1.5.9/src/dispatch_common.h:46^[[m^[[K,                                                from ^[[01m^[[Ksubprojects/libepoxy-1.5.9/src/glx_generated_dispatch.c:26^[[m^[[K:
    ^[[01m^[[K../../home/mangix/devstuff/wrapdb/subprojects/libepoxy-1.5.9/include/epoxy/glx.h:36:10:^[[m^[[K ^[[01;31m^[[Kfatal error: ^[[m^[[KX11/Xlib.h: No su   36 | #include ^[[01;31m^[[K<X11/Xlib.h>^[[m^[[K                                                                                                                 |          ^[[01;31m^[[K^~~~~~~~~~~~^[[m^[[K
    compilation terminated.
    ninja: job failed: cc -Isubprojects/libepoxy-1.5.9/src/libepoxy.so.0.0.0.p -Isubprojects/libepoxy-1.5.9/src -I../../home/mangix/devstuff/wrapdb/subprojects/lIn file included from ^[[01m^[[K../../home/mangix/devstuff/wrapdb/subprojects/libepoxy-1.5.9/src/dispatch_common.h:46^[[m^[[K,                                                from ^[[01m^[[K../../home/mangix/devstuff/wrapdb/subprojects/libepoxy-1.5.9/src/dispatch_glx.c:28^[[m^[[K:
    ^[[01m^[[K../../home/mangix/devstuff/wrapdb/subprojects/libepoxy-1.5.9/include/epoxy/glx.h:36:10:^[[m^[[K ^[[01;31m^[[Kfatal error: ^[[m^[[KX11/Xlib.h: No su   36 | #include ^[[01;31m^[[K<X11/Xlib.h>^[[m^[[K                                                                                                                 |          ^[[01;31m^[[K^~~~~~~~~~~~^[[m^[[K
    compilation terminated.
    ninja: job failed: cc -Isubprojects/libepoxy-1.5.9/src/libepoxy.so.0.0.0.p -Isubprojects/libepoxy-1.5.9/src -I../../home/mangix/devstuff/wrapdb/subprojects/lIn file included from ^[[01m^[[K../../home/mangix/devstuff/wrapdb/subprojects/libepoxy-1.5.9/src/dispatch_common.h:46^[[m^[[K,                                                from ^[[01m^[[K../../home/mangix/devstuff/wrapdb/subprojects/libepoxy-1.5.9/src/dispatch_egl.c:28^[[m^[[K:
    ^[[01m^[[K../../home/mangix/devstuff/wrapdb/subprojects/libepoxy-1.5.9/include/epoxy/glx.h:36:10:^[[m^[[K ^[[01;31m^[[Kfatal error: ^[[m^[[KX11/Xlib.h: No su   36 | #include ^[[01;31m^[[K<X11/Xlib.h>^[[m^[[K                                                                                                                 |          ^[[01;31m^[[K^~~~~~~~~~~~^[[m^[[K
    compilation terminated.
    ninja: job failed: cc -Isubprojects/libepoxy-1.5.9/src/libepoxy.so.0.0.0.p -Isubprojects/libepoxy-1.5.9/src -I../../home/mangix/devstuff/wrapdb/subprojects/lIn file included from ^[[01m^[[K../../home/mangix/devstuff/wrapdb/subprojects/libepoxy-1.5.9/src/dispatch_common.h:46^[[m^[[K,                                                from ^[[01m^[[K../../home/mangix/devstuff/wrapdb/subprojects/libepoxy-1.5.9/src/dispatch_common.c:174^[[m^[[K:
    ^[[01m^[[K../../home/mangix/devstuff/wrapdb/subprojects/libepoxy-1.5.9/include/epoxy/glx.h:36:10:^[[m^[[K ^[[01;31m^[[Kfatal error: ^[[m^[[KX11/Xlib.h: No su   36 | #include ^[[01;31m^[[K<X11/Xlib.h>^[[m^[[K                                                                                                                 |          ^[[01;31m^[[K^~~~~~~~~~~~^[[m^[[K
    compilation terminated.
    ninja: subcommands failed
    

    missing X11 dependency. The build should not have gotten this far.

    opened by neheb 2
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)

  • 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)
Owner
Eric Anholt
Eric Anholt
A Tiny 2D OpenGL based C++ Game Engine that is fast, lightweight and comes with a level editor.

A Tiny 2D OpenGL based C++ Game Engine that is fast, lightweight and comes with a level editor.

Samuel Rasquinha 54 Nov 3, 2022
A simple 2d snake game made using opengl in c++

opengl-snakegame A simple 2d snake game made using opengl in c++ Demo Keyboard Controls P - To resume/start or pause the game R - To restart the game

Dhruv Sawarkar 2 Dec 8, 2021
A minecraft clone built in c++ opengl for the purpose of prefecting graphics programming skills.

LearnOpenGL - CLion This is a project template for OpenGL development with JetBrains CLion IDE. It was created mainly for LearnOpenGL tutorials. Inclu

Jeremy Dellock 1 Dec 28, 2021
FPS Game built from scratch using C++ and Legacy OpenGL.

A small game made by a couple of students as a university project. Built from scratch using C++ and Legacy OpenGL, hence the name.

Yaman Qassas 56 Oct 6, 2022
Game Engine that is being developed by a computer science student using C and OpenGL

Project LOGLE Contents About the Project Project Status Known Issues Setup ?? About Game Engine that is being developed by a computer science student

Ewan 1 Jan 21, 2022
An OpenGL 4.3 / C++ 11 rendering engine oriented towards animation

aer-engine About An OpenGL 4.3 / C++ 11 rendering engine oriented towards animation. Features: Custom animation model format, SKMA, with a Blender exp

Thibault Coppex 29 Nov 22, 2022
GlslViewer is a flexible console-base OpenGL Sandbox to display 2D/3D GLSL shaders without the need of an UI

GlslViewer is a flexible console-base OpenGL Sandbox to display 2D/3D GLSL shaders without the need of an UI

Patricio Gonzalez Vivo 3.7k Nov 23, 2022
A foobar2000 component which allows you to load and play ncm files directly.

Play NCM files directly with our favourite How to setup and build project Download foobar2000 SDK and extract into vendor/sdk Download WTL from source

null 37 Nov 25, 2022
A faster drop-in replacement for giflib. It uses more RAM, but you get more speed.

GIFLIB-Turbo What is it? A faster drop-in replacement for GIFLIB Why did you write it? Starting in the late 80's, I was fascinated with computer graph

Larry Bank 27 Jun 9, 2022
SampPy is a plugin for SA:MP that allows you to create gamemodes from Python

SampPy is a plugin for SA:MP that allows you to create gamemodes from Python. A fork of PySAMP, which has been abandoned for quite some time.

Yahir Vlatko Kozel 16 Jul 31, 2021
Guess a random number between your selected range within the chances you select to win the game!

Number-Guessing-Game Guess a random number between your selected range within the chances you select to win the game! This project was developed by Sa

Sampreet Roy 4 May 13, 2022
In this repository you'll find the fully reversed source code for GTA III (master branch) and GTA VC (miami branch).

Intro In this repository you'll find the fully reversed source code for GTA III (master branch) and GTA VC (miami branch). It has been tested and work

Zero 1 Nov 11, 2021
A Game Boy game that rewards you for playing it on several console models!

GB Corp. A Game Boy game for the Game Boy Competition 2021 by Dr. Ludos (2021) This is the source code, you can get a precompiled rom from here: https

Dr. Ludos 10 Sep 25, 2022
A fun game where you don't press the red ball!

DarkBall DarkBall is a fun to play game where you can press little balls/button, but never press the red ball(or any of its friends) You can find/play

Catermelon 3 Jun 25, 2022
Do you have what it takes? - 2-bit Dungeon Escape game implemented on the Arduino Platform

This game was created as part of the Introduction to Robotics course I took during my 3rd year of studying Computer Science @ University of Bucharest,

Nicoleta Ciausu 6 Feb 28, 2022
Unreal Engine 4 vulnerability, that allows you to run shellcode directly into the target game process.

Unreal Engine 4 vulnerability, that allows you to run shellcode directly into the target game process, to load any DLL undetected from most game anti cheats, such as Easy Anti Cheat, BattleEye, Ricochet, Vanguard, ATG, and more.

Zebratic 46 Nov 17, 2022
The wordle game, but when you want to use sudo!

pam_wordle OS arch Build Status Ubuntu 20.04 x86_64 They say "practice makes perfect", and that is perhaps true. So, let's practice more on the game,

Cocoa 7 Sep 12, 2022
This project is a small 2D game with minilibx. You'll learn about textures, sprites and tiles.

(੭。╹▿╹。)੭ so_long This project is a small 2D game with minilibx. You'll learn about textures, sprites and tiles. Preview How play the game To play thi

ChloeKim 10 Aug 16, 2022
This tool allow you to create / load / edit models used for create a cinematic in game for World of Warcraft 3.3.5 version

CameraCinematic - Discord Introduction This tool allow you to create / load / edit models used for create a cinematic in game for World of Warcraft 3.

Intemporel 9 Mar 14, 2022