dav1dde/glad

Multi-Language Vulkan/GL/GLES/EGL/GLX/WGL Loader-Generator based on the official specs.

glad

Vulkan/GL/GLES/EGL/GLX/WGL Loader-Generator based on the official specifications for multiple languages.

Check out the webservice for glad2 to generate the files you need!

NOTE: This is the 2.0 branch, which adds more functionality but changes the API.

Some languages are only available in the glad1 generator.

Examples

#include <glad/gl.h>
// GLFW (include after glad)
#include <GLFW/glfw3.h>


int main() {
    // -- snip --

    GLFWwindow* window = glfwCreateWindow(WIDTH, HEIGHT, "LearnOpenGL", NULL, NULL);
    glfwMakeContextCurrent(window);

    int version = gladLoadGL(glfwGetProcAddress);
    if (version == 0) {
        printf("Failed to initialize OpenGL context\n");
        return -1;
    }

    // Successfully loaded OpenGL
    printf("Loaded OpenGL %d.%d\n", GLAD_VERSION_MAJOR(version), GLAD_VERSION_MINOR(version));

    // -- snip --
}

The full code: hellowindow2.cpp

More examples in the examples directory of this repository.

Documentation

The documentation can be found in the wiki.

Examples can be found in the example directory. Some examples:

• C/C++
  • GL GLFW
  • GL GLFW On-Demand loading
  • GL GLFW Multiple Windows/Contexts
  • GL SDL2
  • Vulkan GLFW
  • GLX
  • GLX Modern
  • WGL
  • EGL X11
• Rust
  • GL GLFW
  • GL GLFW Multiple Windows/Contexts

License

For the source code and various Khronos files see LICENSE.

The generated code from glad is any of Public Domain, WTFPL or CC0. Now Khronos has some of their specifications under Apache Version 2.0 license which may have an impact on the generated code, see this clarifying comment on the Khronos / OpenGL-Specification issue tracker.

glad's Issues

Web generator for GL-ES is missing GLAPI int gladLoadGL(void);

Hi,
I'd like to report that web generator for GL-ES doesn't generate the function

GLAPI int gladLoadGL(void);

in glad.c .
Regards,
Alessandro

Needs a DUB package

Would be nice to have this available as a DUB package (I don't think there are any other OpenGL loaders out there for D? None that I could find, anyways.)

C: Fill in stubs for get_exts in GLX/WGL

See: #22

Function that are undefined in c/c+, because defined c/c++ in debug version.

I currently noticed that if you download the c/c++ glad file for 4.5 core and use it in a system supports less then 4.5 then in the release build all function pointers that are not available with the version before 4.5 point to nothing, so you could write something like that:

if( !glCopyNamedBufferSubData ) {
     // do some fallback if glCopyNamedBufferSubData does not exists
}

But in the debug build all functions have the _pre_call_callback, _post_call_callback wrapper, so all functions are set even if they are not support by the current platform.

Is the behaviour intended?

Support header-file-only library generation

Would it be possible to add support for header-file-only generation for GLAD? I mean, similar to the stb libraries.

It would be very useful to just drop glad.h into the project and avoid pipeline modification.

Here it is a sample I'm working on; I created the GLAD header-file-only myself manually.

generated documentation and link to online generator

When needing a to add a new extension to glad, it is necessary to return to the generator. Unfortunately, this then requires reselecting all of the prior options manually, and (if you aren't keeping good documentation) trial-and-error to make sure you got all of the ones you need.

It would be extremely convenient if the generated source/header contained a comment that both (a) detailed clearly the specific options used in generation, (b) contained a command line that could be used to regenerate that exact source, and (c) contained a link to the online generator that would prefill all the corresponding options.

Of course, the online generator would need to support a way to set selected items via the URL itself for that last bit to actually be useful.

Something like this in the beginning of the generated glad.h:

/* Generated OpenGL Loader
   by glad 0.1.8a on the 10th of Oct, 2015
     https://github.com/Dav1dde/glad
   License: ... what is the license of the generated output, anyway?
   Options:
     OpenGL 3.3 (Core)
     GL_ARB_sync
     GL_ARB_texture_barrier
     ...
   Command:
     glad --profile core --api gl=3.3 --generator c --spec gl --extensions GL_ARB_sync,GL_ARB_texture_barrier
   Online:
     http://glad.dav1d.de/?profile=core&api=gl%263.3&generator=c&extensions=GL_ARB_sync,GL_ARB_texture_barrier
*/

Enhance gladLoadGLES2Loader?

In some implementations of EGL, eglGetProcAddress will load both core and extension functions. But this isn't always the case and the spec says it's just for extension functions. In this situation - I noticed it with ANGLE on Windows - a different function is needed to load core functions.

The consequence is that when using EGL, the GLADloadproc passed into gladLoadGLES2Loader needs to know what is an extension function and what is not. It's actually a lot more simple if GLAD makes this determination, since it already knows what is a core function and what is an extension.

Just wanted to suggest adding a second signature to gladLoadGLES2Loader that accepts two functions, one for loading core functions and one for extension functions. Then the load_GL_ES_VERSION_* functions use one parameter, while the load_GL_* use the other.

I haven't looked at making the changes to the generator yet though. Does the glad2 branch handle this differently?

406 Not acceptable on OS X

I am not sure why exactly but every simple request on OS X from urlopen and urlretrieve results in 406 errors.

OS X 10.10.4
Python 2.7.6

After some fiddling I realised, that it's related to missing the User-Agent header bit or the accepted mime type stuff. I quickly fixed it by overwriting the global opener instance with one using a sensible User-Agent value.

The commit can be found here: trevex@e5815d1

I'll test it later on my desktop pc running Ubuntu to check whether it breaks anything. I am not an experienced python developer, so let me know if I should send a pull request or you'll fix this in a more idiomatic or cleaner way...

How to use glad on mobile platform with opengles2.0

I'm developing with opengles2.0 for mobile platform(ios/android). I've generated glad with command python main.py --out-path glloader/gles2 --api gles2=2.0 --generator c --spec gl , but there is only gladLoadGLES2Loader, which accepts GLADloadproc load as argument, what should I pass to it on android and iOS?

gladLoadGL() fails on Windows 8.1 x64

I'm compiling with glad.c and glad/glad.h from the "c" branch on github.

When I call gladLoadGL(), it fails, because glGetString() on GL_VERSION returns NULL. Before that fails, it has successfully loaded opengl32.dll and gotten the glGetString function pointer.

The system is Windows 8.1 x64, NVIDIA GTX 870M graphics, driver 340.52. This is an Optimus machine, so it also has an Intel HD 4600 for the actual display framebuffer.

[webservice] Support selecting multiple Specification extensions

Using the web service I noticed you have to choose between OpenGL, EGL, WGL, GLX to add extensions to the list, when you change the Specification, the list is reseted.

It would be great to be able to add OpenGL extensions together with, for example, WGL extensions.

Conflicts between extension function decls (I could just be dumb)

I admit I don't know too much about GL extensions, so I don't know which ones are ancient and shouldn't really be used anymore, buuuut I'm writing an OpenGL binding and I don't know what extensions the users of this binding will need. So I used Glad to generate a loader that loads all extensions (by leaving off the --extensions option).

The resulting (enormous) loader doesn't compile because it seems that there are a number of commands which are required by multiple extensions, so Glad generates multiple declarations for their function pointers. I've commented out the duplicates, and have found out roughly which ones stomp on each other. It's a big list.

GL_ARB_fragment_program/GL_ARB_vertex_program
    glBindProgramARB
    glDeleteProgramsARB
    glGenProgramsARB
    glGetProgramEnvParameterdvARB
    glGetProgramEnvParameterfvARB
    glGetProgramivARB
    glGetProgramLocalParameterdvARB
    glGetProgramLocalParameterfvARB
    glIsProgramARB
    glProgramEnvParameter4dARB
    glProgramEnvParameter4dvARB
    glProgramEnvParameter4fARB
    glProgramEnvParameter4fvARB
    glProgramLocalParameter4dARB
    glProgramLocalParameter4dvARB
    glProgramLocalParameter4fARB
    glProgramLocalParameter4fvARB
    glProgramStringARB
    glGetProgramStringARB

GL_ARB_vertex_program/GL_ARB_vertex_shader
    glDisableVertexAttribArrayARB
    glEnableVertexAttribArrayARB
    glGetVertexAttribdvARB
    glGetVertexAttribfvARB
    glGetVertexAttribivARB
    glGetVertexAttribPointervARB
    glVertexAttrib1dARB
    glVertexAttrib1dvARB
    glVertexAttrib1fARB
    glVertexAttrib1fvARB
    glVertexAttrib1sARB
    glVertexAttrib1svARB
    glVertexAttrib2dARB
    glVertexAttrib2dvARB
    glVertexAttrib2fARB
    glVertexAttrib2fvARB
    glVertexAttrib2sARB
    glVertexAttrib2svARB
    glVertexAttrib3dARB
    glVertexAttrib3dvARB
    glVertexAttrib3fARB
    glVertexAttrib3fvARB
    glVertexAttrib3sARB
    glVertexAttrib3svARB
    glVertexAttrib4bvARB
    glVertexAttrib4dARB
    glVertexAttrib4dvARB
    glVertexAttrib4fARB
    glVertexAttrib4fvARB
    glVertexAttrib4ivARB
    glVertexAttrib4NbvARB
    glVertexAttrib4NivARB
    glVertexAttrib4NsvARB
    glVertexAttrib4NubARB
    glVertexAttrib4NubvARB
    glVertexAttrib4NuivARB
    glVertexAttrib4NusvARB
    glVertexAttrib4sARB
    glVertexAttrib4svARB
    glVertexAttrib4ubvARB
    glVertexAttrib4uivARB
    glVertexAttrib4usvARB
    glVertexAttribPointerARB

GL_EXT_direct_state_access/GL_EXT_draw_buffers2
    glDisableIndexedEXT
    glEnableIndexedEXT
    glGetBooleanIndexedvEXT
    glGetIntegerIndexedvEXT
    glIsEnabledIndexedEXT

GL_EXT_texture_array/GL_NV_geometry_program4
    glFramebufferTextureLayerEXT

GL_NV_gpu_shader5/GL_AMD_gpu_shader_int64
    glGetUniformi64vNV
    glGetUniformui64vNV
    glProgramUniform1i64NV
    glProgramUniform1i64vNV
    glProgramUniform1ui64NV
    glProgramUniform1ui64vNV
    glProgramUniform2i64NV
    glProgramUniform2i64vNV
    glProgramUniform2ui64NV
    glProgramUniform2ui64vNV
    glProgramUniform3i64NV
    glProgramUniform3i64vNV
    glProgramUniform3ui64NV
    glProgramUniform3ui64vNV
    glProgramUniform4i64NV
    glProgramUniform4i64vNV
    glProgramUniform4ui64NV
    glProgramUniform4ui64vNV
    glUniform1i64NV
    glUniform1i64vNV
    glUniform1ui64NV
    glUniform1ui64vNV
    glUniform2i64NV
    glUniform2i64vNV
    glUniform2ui64NV
    glUniform2ui64vNV
    glUniform3i64NV
    glUniform3i64vNV
    glUniform3ui64NV
    glUniform3ui64vNV
    glUniform4i64NV
    glUniform4i64vNV
    glUniform4ui64NV
    glUniform4ui64vNV

GL_EXT_geometry_shader4/GL_EXT_separate_shader_objects (wait, but that's GLES2)
    glProgramParameteriEXT

GL_EXT_direct_state_access/GL_EXT_separate_shader_objects (again, GLES2)
    glProgramUniform1fEXT
    glProgramUniform1fvEXT
    glProgramUniform1iEXT
    glProgramUniform1ivEXT
    glProgramUniform2fEXT
    glProgramUniform2fvEXT
    glProgramUniform2iEXT
    glProgramUniform2ivEXT
    glProgramUniform3fEXT
    glProgramUniform3fvEXT
    glProgramUniform3iEXT
    glProgramUniform4fEXT
    glProgramUniform4fvEXT
    glProgramUniform4iEXT
    glProgramUniform4ivEXT
    glProgramUniformMatrix2fvEXT
    glProgramUniformMatrix3fvEXT
    glProgramUniformMatrix4fvEXT
    glProgramUniformMatrix2x3fvEXT
    glProgramUniformMatrix2x4fvEXT
    glProgramUniformMatrix3x2fvEXT
    glProgramUniformMatrix3x4fvEXT
    glProgramUniformMatrix4x2fvEXT
    glProgramUniformMatrix4x3fvEXT
    glProgramUniformMatrix4fvEXT
    glProgramUniform1uiEXT
    glProgramUniform1uivEXT
    glProgramUniform2uiEXT
    glProgramUniform2uivEXT
    glProgramUniform3ivEXT
    glProgramUniform3uiEXT
    glProgramUniform3uivEXT
    glProgramUniform4uiEXT
    glProgramUniform4uivEXT

I'm a little surprised by GL_EXT_separate_shader_objects conflicting because I generated this loader with just the GL profile, no GLES, so I don't know why the GLES2 bits of that extension are getting loaded. Maybe another bug?

open_gl() returns 0 even if libGL == NULL, is this intended?

EDIT: Nevermind, it returns 1 on success and 0 on failure. That seems...reversed ;-;.

glShaderSource is inconsistent with the specification

The declaration for glShaderSource stated in OpenGL ES 2.0 specification is

void glShaderSource(GLuint shader, GLsizei count, const GLchar * const *string, const GLint *length);

but the generated declaration is this instead

void glShaderSource(GLuint shader, GLsizei count, const GLchar** string, const GLint* length)

Note that the 3rd parameter is missing a const keyword.

I have not looked at generated files for other OpenGL versions, just OpenGL ES 2.0.

Mark D functions as @nogc

I don't think there's a reason for them to not be marked as such.

glPathGlyphIndexRangeNV 'baseAndCount' parameter parsed incorrectly

Unfortunately a single command in gl.xml has a specification unique to all commands (note the [2] at the end):
<param><ptype>GLuint</ptype> <name>baseAndCount</name>[2]</param>

This should be interpreted as a GLuint * according to all the other docs I've found, but is in fact interpreted as a GLuint

The automatically generated C branch is at 4.5?

Although the readme says 4.5.

WGL requires WGL_ARB_extensions_string and WGL_EXT_extensions_string

Currently if you generate a loader without these extensions (WGL_ARB_extensions_string and WGL_EXT_extensions_string) it won't compile.

FR: Support runtime enable/disable of debugging

Currently, we can explicitly disable debugging for individual functions by doing, e.g., glad_debug_glClear = glad_glClear;. It would be nice if glad defined a pair of functions such as gladEnableDebugging and gladDisableDebugging which do this for all functions (enable obviously resetting the function pointers to their original values with callback). That way we could enable/disable debugging on demand at runtime and not only at compile time.

Discussion: Multi-context context loading

Hello and official greetings from the land of GLEW.

With the 2.0.0 release of GLEW support for GLEW MX was dropped due to complications involving core context support. It seems to me a better arrangement for a multi-context (MX) GLEW layered on top of GLEW, rather than existing as a mutant variant of it. There hasn't been an outcry over GLEW 2.0.0, but I've still been browsing here and there for some kind of migration path for GLEW MX applications.

The broad notion that appeals to me for GLEW MX 2 is to layer a per-context struct-of-function pointers on top of GLEW (or whatever other native function loader) and simply generating code for populating the appropriate state from the vanilla GLEW function pointers and extension flags. It seems that glad might be an appropriate solution for generating GLEW MX, as an alternative back-end. This also has the advantage of being able to mix single-threaded (main thread) and multi-threaded code into same codebase.

There would be some complication in terms of glad accepting the GLEW-style extension specifications.(The XML is only a subset of what GLEW supports) Perhaps the more ideal arrangement is for glad to natively support multi-context use cases, is that already the case? In that case I'd be happy to recommend glad as the MX migration path beyond GLEW 1.13.0.

Some other discussion is here:
nigels-com/glew#38

• Nigel

glad-egl.h has duplicated declaration of gladLoadEGLLoader() function

Hi !
Web generator outputs duplicate declaration of gladLoadEGLLoader
Line 33: GLAPI int gladLoadEGLLoader(GLADloadproc);
Line 36:GLAPI int gladLoadEGLLoader(GLADloadproc);

Add support for Vulkan

Adding initial support for the Vulkan API would be super helpful and awesome

Remove the khrplatform.h header

Nothing that is defined in the khrplatform.h header seems to be used. So, that header file does not need to be included when you remove the following line from the glad.h output:

#include <KHR/khrplatform.h>

GL_STACK_OVERFLOW and GL_STACK_UNDERFLOW seem to be undefined

I've just generated an OpenGL 2.1 glad zip from the web service (I'm trying to switch a quite large project away from GLEW) and it appears GL_STACK_OVERFLOW and GL_STACK_UNDERFLOW are undefined. In fact, this is the section in glad.h where they should be...

#define GL_NO_ERROR 0
#define GL_INVALID_ENUM 0x0500
#define GL_INVALID_VALUE 0x0501
#define GL_INVALID_OPERATION 0x0502
#define GL_OUT_OF_MEMORY 0x0505

Notice that it jumps from 0x0502 to 0x0505 :)

Avoid #include "windows.h", just relevant parts (like GLFW3)

I want to use glad in my project (raylib) but some symbols defined by windows.h conflict with my symbols. If I comment #include "windows.h" on glad.h everything compiles fine but programs crash on init.

Would it be possible to include only the required windows.h parts into glad.h?

GLFW3 works this way.

Allow strict compiler flags (-Wall -Wextra -Werror -pedantic)

I will begin by saying thank you for this project! :)

Using -pedantic with GCC (tested with 5.3.0) will result in a lot of the following warnings (or errors for us using -Werror):
ISO C forbids conversion of object pointer to function pointer type

I solved it by modifying my generated glad.h:

typedef void (*GLADvoidfn)(void);
typedef GLADvoidfn (*GLADloadproc)(const char *name);

This will avoid the casts from pointer-to-void to pointer-to-function inside glad.

In my calling code I also needed to add this since I use SDL which also uses pointers-to-void for function pointers:

static GLADvoidfn
getprocaddress_wrapper(const char *name)
{
#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-pedantic"
    return (GLADvoidfn) SDL_GL_GetProcAddress(name);
#pragma GCC diagnostic pop
}

I have not tried this on other compilers yet.
Would you like a pull request?

web generator : glad_egl.h miss definitions from egl.h

Hi
glad_egl.h miss definitions for EGL 1.0 and forward.
i.e. unable to find things like

define EGL_NO_CONTEXT ((EGLContext)0)

define EGL_NO_DISPLAY ((EGLDisplay)0)

define EGL_NO_SURFACE ((EGLSurface)0)

define EGL_PBUFFER_BIT 0x0001

executing my code gives symbol lookup error undefined symbol: glad_glGenTextures

on executing my code I am facing this error
./sample2D: symbol lookup error: /usr/local/lib/libftgl.so.2: undefined symbol: glad_glGenTextures

all: sample2D

sample2D: Sample_GL3_2D.cpp glad.c
        g++ -o sample2D Sample_GL3_2D.cpp glad.c -lGL -lglfw -lGLU -lftgl -ldl -std=c++11

clean:
        rm sample2D

this is my Makefile

Option to add argument names to function macros in glad.h

I have made a quick modification to GLAD to generate argument names for the macros in glad.h, so I can use my IDE to see the GL function signature. Otherwise, I find myself having to look up the documentation for less common GL functions as I'm writing code.

For example, this:

#define glTexImage2D glad_glTexImage2D

Is instead generated as:

#define glTexImage2D(GLenum_target, GLint_level, GLint_internalformat, GLsizei_width, GLsizei_height, GLint_border, GLenum_format, GLenum_type, const_voidp_pixels) glad_glTexImage2D(GLenum_target, GLint_level, GLint_internalformat, GLsizei_width, GLsizei_height, GLint_border, GLenum_format, GLenum_type, const_voidp_pixels)

I'm willing to submit this feature as a pull request if anyone's interested (it works great for me). If so, should I base it on the master branch, or glad2? I'm new to GitHub so I'm not sure what kind of preferences the project author might have with regard to patches. Thanks!

GLversion in the C loader

'"glad.h" contains a definition of GLVersion instead of a mere declaration.
extern should be used with a single definition in "glad.c".

Proposed patch:

diff --git a/glad/loader/gl/c.py b/glad/loader/gl/c.py
index 0b72d99..e5a361b 100644
--- a/glad/loader/gl/c.py
+++ b/glad/loader/gl/c.py
@@ -15,6 +15,8 @@ int gladLoadGL(void) {
 '''

 _OPENGL_HAS_EXT = '''
+struct gladGLversionStruct GLVersion;
+
 static int has_ext(const char *ext) {
     if(GLVersion.major < 3) {
         const char *extensions;
@@ -82,7 +84,7 @@ _OPENGL_HEADER = '''
 #define GLAPI extern
 #endif

-struct {
+extern struct gladGLversionStruct {
     int major;
     int minor;
 } GLVersion;

Missed SPIR-V?

I trying type "SPIR-V", "spirv", "spir", etc., but no any response.
http://glad.dav1d.de/

unused function 'has_ext'

I'm getting a compiler warning of an unused function has_ext. I know I can just ignore the warning or turn it off, but do you think one could somehow avoid including a static function if it is actually not used anywhere in the file?

With these settings:

http://glad.dav1d.de/#profile=compatibility&language=c&specification=gl&api=gl%3D3.3

I'm getting this warning:

glad.c:75:12: warning: unused function 'has_ext' [-Wunused-function]
static int has_ext(const char *ext) {

perhaps obvious bug with glad/loader/gl/c.py on my OpenGL 3.*0* box ^^;;

hdon beat me to it ^^

Support multiple profile in one application

Hello,

My idea is to support both OpenGL 3.2 core profile and OpenGL 2.1 compat as a fallback, does that make any sense do that at runtime ?
Technically, I was about to hide all opengl calls in a wrapper, and including the glad.c file for each supported version (without exporting any symbols).
The other solution that came to mind was to export two loading functions, one for load 2.1-compat and one for 3.2-core. Then, I simply use the 3.2 core header file everywhere in the project (to avoid using the old API) for the GL_ defines, while still hiding the function calls using a wrapper.

How does one build a binary that can use two different versions of OpenGL ?

The function glProgramParameteri does not get generated

The function glProgramParameteri is unavailable in a generated header file that includes the GL_ARB_separate_shader_object extension. glProgramParameteri is clearly listed as being part of that extension at https://www.opengl.org/registry/specs/ARB/separate_shader_objects.txt. Other functions that are part of this extension are available.

I use Glad on Windows with the following command, altough I don't think that is part of the problem:
python Glad\main.py --profile=core --out-path="%CD%" --api="gl=3.3" --spec=gl --extension="GL_ARB_separate_shader_objects" --generator=c --omit-khrplatform --local-files

The generated header file looks like this:
glad.h.txt

can not access khronos .xml spec due to robots.txt

python2 main.py --out-path=./ --generator=c does not work

it fails on downloading specs from khronos:
https://cvs.khronos.org/svn/repos/ogl/trunk/doc/registry/public/api/gl.xml

looks like it is blocked by robots.txt

https://www.google.pl/?gws_rd=ssl#q=https:%2F%2Fcvs.khronos.org%2Fsvn%2Frepos%2Fogl%2Ftrunk%2Fdoc%2Fregistry%2Fpublic%2Fapi%2Fgl.xml

c-debug output errors

Hey,
The library is great in normal C mode, but when I generate using the c-debug generator the output is unusable.

Inside glad.c the errors start at line 235:
APIENTRY PFNGLCOPYTEXIMAGE1DPROC glad_glCopyTexImage1D;
syntax error: identifier 'glad_glCopyTexImage1D'

And there are about 100 or so. I've uploaded my output here:
https://github.com/zach2good/glad/tree/c-debug

But it appears to be the same as the debug output from your web generator. I've tried dropping the gl api level down and removing al lthe extensions but still no luck. Is there something I'm missing?

Cheers

Extension selection doesn't seem to work properly

Consider:

python main.py --profile=core --out-path=testloader --api="gl=" --generator=c --spec="gl" --extensions="GL_AMD_gpu_shader_int64"

Works fine.

python main.py --profile=core --out-path=testloader --api="gl=" --generator=c --spec="gl" --extensions="GL_AMD_gcn_shader,GL_AMD_gpu_shader_int64"

Now I get an error saying GL_AMD_gpu_shader_int64 is invalid.

I think the problem is in glad/generator/generator.py. The generate method does:

        e = chain.from_iterable(self.spec.extensions[a] for a in self.api)
        for ext in extension_names:
            enforce(ext in e, 'Invalid extension "{}"'.format(ext), ValueError)

But I think it should be e = list(chain.from_iterable(self.spec.extensions[a] for a in self.api)). Changing it to this works properly.

Wrong GLversion in OpenGL ES

GL_VERSION string is formatted differently in OpenGL ES 1 & 2 than it is in plain OpenGL and OpenGL ES 3.

See man pages:
https://www.opengl.org/sdk/docs/man4/html/glGetString.xhtml
http://www.khronos.org/opengles/sdk/1.1/docs/man/glGetString.xml
http://www.khronos.org/opengles/sdk/docs/man/xhtml/glGetString.xml
https://www.khronos.org/opengles/sdk/docs/man3/html/glGetString.xhtml

D loader, some issues

Had to change a few things in the D generated loader to get it working for me:

https://github.com/Dav1dde/glad/blob/d/glad/glad/wgl/types.d#L16
had to change to

public import core.sys.windows.windows;

https://github.com/Dav1dde/glad/blob/d/glad/glad/wgl/loader.d#L18
had to replace with:

import glad.gl.loader : gladGetProcAddressPtr;

i.e. just use the one in gl. Without this, I get 'Previous definition different' errors.

The public import of core.sys.windows.windows made this:
https://github.com/Dav1dde/glad/blob/d/glad/glad/wgl/loader.d#L165
conflict with another definition, so I had to comment this out. These functions are in gdi32.lib anyway, not sure why glad is trying to load them from opengl?

And finally I commented out the close_gl() lines from both wgl.loader and gl.loader. Could closing be made optional?

I am using the D loader as a derelict replacement, creating opengl context from scratch. Maybe my use case is not what is intended, and lead to these problems, not sure, just thought I'd share.

Thanks!

Potential memory leak.

There's a potential memory leak in get_exts. realloc can return null. If it does exts_i will be null and you'll have leaked the memory exts_i was previously pointing to (realloc doesn't free the previous block if the new block couldn't be allocated). Then you'll deference it in the proceeding loop.

fatal error: typedef redefinition with different types on OSX

As explained in this issue, it seems OSX already includes GLsizeiptr and a few others. The same problem happens with glad.h as well. The workaround appears to be to use long instead of ptrdiff_t. Here's another example.

Adding install target to cmake

Would it be possible to add install targets to the cmake build? I did a quick try to include this library as an external project dependency in a local project, but as glad does not build as a standard library with install (instead using parent scope sets, which does not work for external projects), I've currently hit somewhat of a wall.

could be solved (?) by something as simple as:

install(TARGETS glad ARCHIVE DESTINATION lib)
install(FILES ${GLAD_HEADERS} DESTINATION include)

assuming the header(s) could be accessed separately from the source(s).

Auto-complete friendly function prototypes

Is it possible to mimic same behavior like glcorearb.h with GL_GLEXT_PROTOTYPES defined? Current implementation hides function prototypes and makes auto-complete feature of IDEs almost useless.

Thanks!

How to include GL_KHR_debug extension

Hello. I'm trying to include GL_KHR_debug extension, but I'm failing to do so somehow:

python2 main.py --profile=core --out-path=GL --generator=c --extensions=GL_EXT_texture_compression_s3tc,GL_KHR_debug

output:

Downloading latest spec from svn...
Generating gl bindings...
Traceback (most recent call last):
  File "main.py", line 129, in <module>
    main()
  File "main.py", line 123, in main
    generator.generate(ns.extensions)
  File "/home/siavash/Documents/Development/Sources/glad/glad/generator/generator.py", line 43, in generate
    enforce(ext in e, 'Invalid extension "{}"'.format(ext), ValueError)
  File "/home/siavash/Documents/Development/Sources/glad/glad/generator/util.py", line 7, in enforce
    raise exc(message)
ValueError: Invalid extension "GL_KHR_debug"

Thanks!

Segfault: C 'get_exts()' doesn't differenciate OpenGL context from OpenGLES one

I generate glad for OpenGL 3.0 and Open GL ES 2.0 (--api=gl=3.0,gles2=2.0).
Calling gladLoadGLES2Loader within an Open GL ES 3.0 context causes a segfault in get_exts by trying to call glGetStringi and glGetIntegerv (both NULL pointers) instead of glGetString.

Those functions aren't supposed to be loaded. get_exts uses them because of the 3.0 context without considering if we're given an OpenGL or an OpenGL ES one.

This could be considered a follow up of issue #6.

Web Generated glad.h uses wrong define to check GL-ES 2 api

Hi !

The generated glad.h for GL-ES 2 uses the following check :

ifdef _gl_h

error OpenGL header already included, remove this include, glad already provides it

endif

But I guess it should be

ifdef _gl2_h // as stated at /GLES2/gl2.h

error OpenGL ES header already included, remove this include, glad already provides it

endif

Regards !

Using GLAD as submodule does not generate .h and .c files when running CMake

I'm currently trying to build my project from sources and included GLAD as a submodule.
When I execute CMake with "configure" and "generate" the .h and .c do not appear.
In the GLAD CMakeLists.txt is the add_custom_command(...) which should generate those files.
When I run Python manually and execute your main.py, everything works, only CMake does not run and generate the header and source file?

It outputs only to following message, without having the two files generated
GLAD_SOURCES:
.../build/extern/glad/src/glad.c
.../build/extern/glad/include/glad/glad.h

I'm adding GLAD with
add_subdirectory(extern/glad)

Am I doing something wrong, or is something missing in my projects CMakeLists.txt?

Thanks for your help!

Crash on WGL call

Hello, I'm using just a few features of WGL so that I can disable VSync on Windows. However, it seems whenever I call wglSwapIntervalEXT(0), my program crashes. Everything else works and I can call regular GL functions, but WGL seems to be crashing

C Loader for gles1 / gles2 only fails to compile

A C loader generated for those, without plain gl, fails to compile.

has_ext function uses the glGetStringi function and the GL_NUM_EXTENSIONS constant but they are neither defined in gles1 nor in gles2.