Dav1dde/glad: generating OpenGL, Vulkan and EGL loaders from the official specs

The problem glad2 solves: symbol resolution without a runtime dispatcher

On Windows, opengl32.dll exports only OpenGL 1.1. Everything past that, and every extension, has to be fetched at runtime through wglGetProcAddress or an equivalent per-platform call. On Linux the same job falls to glXGetProcAddress, on EGL to eglGetProcAddress. Writing that resolution layer by hand means hundreds of function pointers, each with a signature that must match the Khronos header exactly, and each guarded by a check for whether the driver actually exposes it.

glad2 generates that layer for you. You tell it which API (gl, vulkan, gles2, egl, glx, wgl), which version, which profile and which extensions you want. It reads the official specification files and emits a header plus a source file where every requested entry point is a function pointer, plus a loader function that fills them in. The audience is people writing C or C++ graphics code who want the set of resolved symbols to be a build-time decision rather than a runtime string lookup. It also emits Rust, and the repository ships Rust examples under example/rust/.

How the generator works: specifications, Jinja2 templates and Python entry points

The repository layout separates four concerns. glad/specification/ holds parsers for the Khronos XML registries (egl, gl, glx and others are registered as entry points under the glad.specification group). glad/generator/ holds the language backends; pyproject.toml registers c and rust under the glad.generator entry point group, pointing at CGenerator and RustGenerator. Templates are rendered with Jinja2, which is the project's only declared runtime dependency, pinned as Jinja2>=2.7,<4.0 in both pyproject.toml and requirements.txt. The glad/ package also exposes a console script named glad.

The entry point groups matter because they define the extension model. A new language backend is a Python package that registers itself in glad.generator; a new specification is one registered in glad.specification. That is what the wiki page on extending glad describes, and it is why the community Fortran plugin exists as a separate repository rather than a patch to this one. The generator itself does not care about graphics APIs; it cares about a spec object and a template set.

Installing glad2 and generating a first GL loader

The distribution name on PyPI is glad2, not glad, which is a common source of confusion when the console script is called glad. The README does not spell out a pip invocation, so the package name below comes from the [project] table in pyproject.toml.

python -m pip install glad2

After installation the console script is available. The README does not document the individual CLI flags, so check the options your installed version accepts before you build a script around them. The repository does ship a CMake integration under cmake/, and the README points at the wiki for documentation.

The README gives this initialization pattern, which is the contract the generated header expects:

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

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

The include order is deliberate: glad must come before GLFW so that the generated header, not the system GL header, supplies the declarations. A zero return means the loader could not resolve the requested functions against the current context, which in practice means the context was not current or the driver is older than the requested version. Add the generated include directory to your compiler's search path and compile the generated source file into your target.

What glad2 does not do, and when a different tool fits better

glad2 emits code; it does not ship a prebuilt library you link against and forget. That means the generated files become part of your source tree or your build artifacts, and regenerating them is a step someone has to own. The README is explicit that this is the 2.0 branch, that it adds functionality but changes the API, and that some languages are only available in the glad1 generator at glad.dav1d.de. If your project is written in a language that only glad1 supports, glad2 is simply the wrong branch, not a worse version of the right one.

The on-demand loading example (example/c/gl_glfw_on_demand.c) is worth reading before you assume the default behaviour is what you want. Resolving every symbol at startup costs time and memory for functions your program may never call; the on-demand variant trades a check on first use for a smaller initial footprint. Neither is free.

The clearest comparison is GLEW. GLEW is a library you build or install once and link against; it initializes the whole extension set it knows about. glad2 inverts that: the extension set is fixed at generation time by the flags you pass, so the binary contains pointers only for what you asked for, at the cost of a generation step in your build. If you want a fixed dependency you can install from a system package and call glewInit(), GLEW is the shorter path. If you want the symbol set to be an explicit, reviewable artifact, glad2 is the one that gives you that.

Maintenance, licensing and what generation commits you to

The glad2 branch saw its last push on 2026-06-18. The most recent release listed is v2.0.8 from 2024-09-29, with v2.0.7 and v2.0.6 before it. The gap between the latest tag and the latest branch activity means anyone depending on tagged releases is working with code that is older than the branch head, and should say so in their own dependency notes.

On licensing, the README draws a line between the generator and its output. The source code and the various Khronos files are covered by the repository LICENSE. The generated code is stated to be any of Public Domain, WTFPL or CC0. The README then adds a caveat: some Khronos specifications are now under Apache Version 2.0, which may affect the generated code, and it links to a clarifying comment on the Khronos OpenGL-Registry issue tracker. That is a real ambiguity rather than a settled answer, and it is the thing to check against your own distribution requirements before you ship generated files. The classifier in pyproject.toml lists MIT for the package itself, which is a separate question from the license of what the package emits.

The upgrade cost is mostly regeneration plus recompilation, but the README's note that glad2 changes the API relative to glad1 means a migration from the older branch is not a drop-in. Verify the generated header's loader signature and include paths against your existing call sites rather than assuming the old names survive.

Generating from the web service instead of the CLI

The README opens by pointing at the webservice at glad.sh, and the repository homepage is gen.glad.sh. For a one-off loader this is the lower-friction route: pick the API, version and extensions in the browser, download the archive, and drop it into your tree. The CLI and the web service are two front ends over the same generator, so the output shape is the same.

The trade-off is reproducibility. A loader downloaded from a web page has no record of which generator version produced it, and the repository's own release history shows the generator does change. The CLI path lets you record the exact glad2 version and the exact arguments in your build files, so a regenerated loader can be reviewed as a diff. If the loader is going into a repository that other people build, that record is the thing that survives an audit. If you are prototyping and will throw the tree away, the web service is faster and the reproducibility question never comes up.

Editorial conclusion

Adopt glad2 if you ship a native graphics application and want a loader containing only the extensions you actually call, generated for your target platform and language. Do not adopt it if you want a runtime dispatcher you can drop in without a build step, or if you need a language the glad2 branch does not generate; the README points those users at the glad1 generator at glad.dav1d.de. Before committing, verify two things in the generated output: that the feature set you passed to the generator covers every symbol your renderer references, and that the license of the generated files matches what the README says for the specific Khronos specifications you enabled. The last push to the glad2 branch was on 2026-06-18, and the newest tagged release listed is v2.0.8 from 2024-09-29, so pin the version you generate with and keep the generator invocation in version control alongside the output.

Frequently asked questions

Official sources

1. Dav1dde/glad on GitHub
2. Issues
3. Project website
4. README
5. Releases