GLEW: runtime OpenGL extension loading for C and C++ projects

The problem GLEW solves for OpenGL callers

OpenGL does not ship as a library that exposes every function it defines. The operating system provides a small set of core entry points, and everything beyond that is reached by asking the driver at runtime whether a named extension exists and where its function lives. Writing that resolution by hand means a table of function pointers, a string comparison per extension, and a different lookup path on Windows (wglGetProcAddress), Linux with GLX (glXGetProcAddress), and EGL. GLEW does that work once and exposes the result as ordinary symbols.

The README states that GLEW provides "efficient run-time mechanisms for determining which OpenGL extensions are supported on the target platform" and that "OpenGL core and extension functionality is exposed in a single header file." That single header is the whole selling point. You include it, call glewInit once after your context exists, and then call extension functions directly. The audience is C and C++ developers who ship one binary to many machines and cannot know at compile time which extensions the target driver will expose.

How the extension table is built and queried

The repository is organised around a generator rather than a hand-maintained source file. The top level holds auto/, config/ and src/, and the README describes a code generation workflow that is "a complex brew of gnu make, perl and python" and works best on Linux or Mac. The auto/ directory is where the extension specification data is turned into the generated headers and source that end up in src/. That is why the README warns you may need to call make in the auto folder first, and why it recommends building from a release snapshot instead of a git checkout: the snapshot already contains the generated output.

The runtime side is a lookup pass. After a context is current, glewInit queries the driver for each extension the library knows about and fills in the function pointer table. Code then tests the boolean flags GLEW exposes, such as GLEW_ARB_... style macros, before calling anything. The topics list on the repository names the platform layers that get bridged: glx, wgl, egl, plus the glewinfo and visualinfo diagnostic tools. Per-platform documents sit alongside the main README as GLXEW.md, WGLEW.md and EGLEW.md, so each windowing system has its own description of what is wrapped.

Building GLEW from a release snapshot on Linux

The README recommends the tgz or zip release snapshot over a git clone, because the generated sources are already present. Download glew-2.3.1.tgz, unpack it, and install the build dependencies listed for your distribution. On Debian, Ubuntu or Mint the documented command is:

sudo apt-get install build-essential libxmu-dev libxi-dev libgl-dev

Then build and install from the unpacked directory. The README lists the make targets as all, glew.lib (with sub-targets glew.lib.shared and glew.lib.static), glew.bin, clean, install and uninstall, and names the variables SYSTEM, GLEW_DEST and STRIP.

make
sudo make install

GLEW_DEST defaults to /usr/local, so the headers land under that prefix and the shared library goes to the library directory beneath it. If you are on a system where the default guess is wrong, set SYSTEM explicitly, for example SYSTEM=linux-clang. For EGL-only work the README gives a separate path:

sudo apt install libegl1-mesa-dev
make SYSTEM=linux-egl

The cmake route is also documented, requires CMake 3.16 or higher, and is described as "mostly contributor maintained" and handled on a best effort basis. Its targets are glew, glew_s, glewinfo, visualinfo, install, clean and all, with BUILD_UTILS, GLEW_REGAL, GLEW_OSMESA, BUILD_FRAMEWORK and CLANG_TIDY as the documented variables. On Windows, the README points at the provided Visual Studio project under build/vc15/ and notes that projects for vc6, vc10, vc12 and vc14 are also present; MSYS2 users install toolchains with pacman before running make.

Checking what your driver actually exposes with glewinfo

glewinfo is the first thing worth running after a build, and it is the reason the diagnostic tools exist. It is built by the cmake target of the same name when BUILD_UTILS is ON, and it is part of the glew.bin make target. Running it prints the extensions and core versions the current context reports. That output is the practical contract for your renderer: if glewinfo on the target machine does not list an extension, no amount of linking will make the corresponding function callable.

visualinfo is the companion tool, also gated behind BUILD_UTILS in the cmake build, and it reports the available pixel formats and visual configurations. On a headless Linux box the README documents an off-screen path, installing libosmesa-dev and building with make SYSTEM=linux-osmesa, or setting GLEW_OSMESA in the cmake build. That matters because glewinfo needs a current context to say anything useful, and on a build server there may be no display to create one against.

Where GLEW is the wrong choice

The library resolves extensions, not API versions. If your code is written against a modern core profile and you would rather not carry a pointer table for functions the driver is guaranteed to provide, a generated loader tuned to exactly the functions you call will produce a smaller surface. GLEW's single header exposes everything it knows about, which is the feature and also the cost.

The build story is the second limit. The README is explicit that code generation is a "complex brew" and that it works best on Linux or Mac, with Windows support through MSYS2. If you need to regenerate the extension tables rather than consume a snapshot, you are maintaining a perl and python toolchain alongside your C compiler. The README also notes that the cmake build is contributor maintained on a best effort basis, so a cmake-only workflow is a different support tier from the GNU Make path, which it calls the primary build system historically.

Licensing needs a look before you vendor it. The repository's licence is reported as NOASSERTION, and LICENSE.txt sits at the top level next to the source. The Makefile carries a three-clause BSD style notice that requires the copyright notice and disclaimer in source and binary redistributions, forbids using the author's name to endorse derived products without permission, and disclaims warranty. Those per-file terms, not a single SPDX tag, are what a redistribution has to satisfy.

GLEW against a generated loader such as GLAD

The comparison people actually search for is GLEW versus GLAD, and the difference is in how the function table comes to exist. GLEW ships a prebuilt table covering everything in its generated extension set and decides at runtime which entries are valid. A generated loader takes the opposite direction: you feed it the exact set of functions and extensions your code uses, it emits a header and a source file for that set, and there is no runtime enumeration of extensions you never call.

The practical consequences run both ways. A generated loader gives you a smaller binary and no dependency to install, at the cost of regenerating whenever you add a call. GLEW gives you a stable dependency, a package that distributions already carry, and the glewinfo and visualinfo tools for diagnosing a machine you cannot sit in front of. If you are chasing a bug on someone else's hardware, having glewinfo available is worth more than a few kilobytes of unused pointer table. The README does not compare GLEW to any other loader, so treat the trade-off as a design question rather than a documented claim.

Maintenance, releases and upgrade cost

The last push to the repository was on 2026-09-21, and the project is not archived. Release 2.3.1 is dated 2026-01-24, following 2.3.0 on 2025-12-21. The gap before those two is instructive: 2.2.0 is dated 2021-01-10, so roughly five years separate it from 2.3.0. Upgrades therefore arrive in bursts after long quiet periods, which is fine for a library whose job is to track a specification that also moves slowly, but it means you should not plan around a steady release cadence.

Upgrade cost is low if you consume a release snapshot. The generated sources are in the tarball, so moving from 2.2.0 to 2.3.1 is a rebuild and a reinstall, not a regeneration. The cost rises if you patch the generator or maintain your own extension additions, because the auto/, config/ and src/ layout means your changes sit in the same tree the generator writes to. The repository also carries a HISTORY.md for release notes and a CLAUDE.md at the top level, which suggests contributors are expected to read more than the README before changing things.

Editorial conclusion

Adopt GLEW if you maintain a C or C++ renderer that must run against whatever OpenGL driver the user happens to have, and you want one header plus a runtime query instead of hand-written per-platform loader code. Skip it if you are writing a modern shader pipeline in Rust, Go or JavaScript, or if you only ever target one GPU and one driver version. Before committing, build glewinfo on your own machines and check which extensions it reports, because that output is the actual contract your code will run against. Also read LICENSE.txt and the licence headers in the Makefile, since the project's licence identifier is NOASSERTION and the per-file terms are what apply.

Frequently asked questions

Official sources

1. Issues
2. nigels-com/glew on GitHub
3. README
4. Releases