freeglut: a maintained free GLUT for OpenGL programs that must stay portable

The compatibility promise is the whole point

Freeglut is meant to be a free alternative to Mark Kilgard's GLUT library. The overview is explicit that freeglut is free software distributed under an MIT/X11 style licence, and that you are free to use, modify and redistribute it with or without modifications, with the details in the COPYING file.

The commitment that defines the project is compatibility. Freeglut is both source and binary compatible with the original GLUT and can be used as a drop-in replacement for it. The maintainers describe maximum compatibility as one of the main goals, and say they take care to maintain a stable API and ABI and to introduce new features in a way that does not compromise compatibility.

That combination explains why the library still exists and still matters. A GLUT program written in the 1990s, with its window creation, context handling and event loop in a handful of callbacks, can be rebuilt against freeglut and keep working, including at the binary level, which matters when you have libraries built against the original that you cannot rebuild.

The trade is obvious and worth stating early: a frozen compatibility surface is also a frozen design. The API will not gain the conveniences a modern windowing library would provide, and that is a deliberate choice rather than an oversight.

Windows, contexts and input events, without platform specific code

The set of tasks freeglut handles is narrow and clearly drawn. Those are the tasks that would normally require platform specific code: creating a window, creating an OpenGL context and binding it to the window, and processing input events.

The value is in the platform independence rather than in any cleverness. The project describes the API as concise and elegant, and the goal as keeping the application simple and portable. On Linux that means the same program works whether the display server is X11 or Wayland, on Windows the window creation and context binding are handled for you, and on macOS the same source builds against either XQuartz or the native Cocoa path.

Because the API is stable and the behaviour is fixed, the program reads as a sequence of callbacks rather than as a loop you wrote yourself. That is the historical appeal of GLUT and the reason a large body of teaching material and older research code uses this shape.

The library is written in C, and the repository layout is conventional for such a project: include for the public headers, src for the implementation, progs for example programs, doc for documentation, man for manual pages, and a set of per platform directories for Android, the Nintendo targets and the CMake modules.

Nine platforms, and a CI matrix that shows which ones are real

The port list reads like a map of where OpenGL software still runs. Supported are UNIX systems with X11 or Wayland, such as GNU/Linux, FreeBSD and IRIX, MS Windows, macOS with XQuartz by default or native Cocoa which is marked experimental, Android through the NDK, BlackBerry, and the Nintendo GameCube and Wii.

The build badges at the top of the README tell you which of those are continuously verified, and the list is more informative than the port list itself. There are workflows for GNU/Linux on X11, FreeBSD on X11, Windows with MSVC, Windows with MSVC 6.0, Windows with MinGW, macOS on X11 and macOS on Cocoa.

Two observations follow. First, a Windows build with MSVC 6.0 is still in the matrix, which is a direct consequence of the compatibility promise and tells you how seriously the ABI stability is taken. Second, the Cocoa workflow exists, which means the experimental path is at least continuously compiled even if its runtime support level is not the same as the others.

The README also asks you to consult the platform specific readme files for the level of support and the build instructions, and those files are visible at the top level of the repository: README.android, README.blackberry, README.cmake, README.macos, README.mingw_cross and README.ogc for the Nintendo targets.

Building through cmake, with an unofficial escape hatch

Freeglut relies on cmake, with a minimum version of 3.1.0, to generate the build files for all the different supported platforms and toolchains. A single CMakeLists.txt sits at the root of the repository, with the CMake modules in a cmake directory.

cmake

The README points at README.cmake as the starting point, and at the other readme files for further information. That is the documentation pattern for this project: the top level README describes the project, and each platform gets its own file with the specifics of building there.

For the cases where cmake is inconvenient, the project also provides a set of alternative build files, and the description is unusually honest about their status: unofficial, unsupported, possibly unmaintained, but potentially useful. They live in an altbuild directory with their own readme.

The distinction matters if you are deciding how to depend on the project. The cmake path is the supported one and the one the CI matrix exercises. The altbuild path exists for toolchains that cmake handles badly, and using it means accepting that you are on your own when it breaks.

The sources themselves are C, and the build produces the library plus the example programs in the progs directory, which are the quickest way to check that a port behaves on your machine.

From OpenGL 1.0 on SGI hardware to core profiles and OpenGL ES

The range of OpenGL implementations freeglut can be used with is one of its less obvious strengths. The project states it works with a wide range of implementations, from the very early OpenGL 1.0 on SGI computers to the very latest modern OpenGL versions on current GPUs.

Context creation is where that range becomes concrete. Freeglut can create a classic OpenGL context, a versioned core profile context, or a compatibility context. Those are three different requests with different consequences for what your shaders and fixed function code can do, and the ability to ask for a compatibility context is what keeps older GLUT programs running unchanged on a modern driver.

It can also be used with OpenGL ES, on desktop or mobile devices. That line matters more now than when it was written, because a project that has to run the same rendering code on a workstation and on a phone has one windowing abstraction to keep rather than two.

Taken together with the platform list, the picture is a toolkit whose reach is broad and whose interface is fixed. The compatibility surface is a feature when you are maintaining old code, and a constraint when you are writing something new and would rather use the platform API directly.

Version 3.8.0 in November 2025 with commits still landing in 2026

The release history shows a project with a long life and an irregular rhythm. The tagged releases are v3.8.0 from 2025-11-16, v3.6.0 from 2024-06-11 and v3.4.0 from 2022-10-07, and the last push was on 2026-08-28. The default branch is master, and the repository is not archived.

So the code is being worked on, and the tags come less often than the commits. That is normal for a library whose whole purpose is to stay compatible, since most changes are fixes and platform adjustments rather than new API.

On licensing, the licence field on the repository carries a custom classification that GitHub cannot label, and the authoritative text is the COPYING file, which the overview describes as an MIT/X11 style licence. That wording matches what most Linux distributions ship today, and it is the reason the project has survived in the dependency lists of so much old code.

The project still lives partly on SourceForge: the website is freeglut.sourceforge.net, and the mailing lists, developer, bugs and announce, are hosted there. The bug trackers on SourceForge are described as still reachable for older reports, while new issues are encouraged to go through the GitHub issue system. Patches and pull requests are welcome, with the mailing list named as the place for extended discussion about features and design issues for large contributions.

One detail that dates the project: the contribution notes ask that mailing list posts avoid daily digest mode, do not top-post, and be hard wrapped at 72 columns with no binary attachments. That is a formality from the era when the list was the primary channel, and it is still written into the README.

Editorial conclusion

Adopt freeglut when you maintain an OpenGL program that must keep building on several platforms, when a drop-in replacement for the original GLUT saves a porting effort, or when you are teaching OpenGL and want a toolkit that still runs. Do not adopt it when you are starting a new project, because the windowing API it offers is deliberately frozen in the shape of a library from the 1990s, and treat the macOS Cocoa port and the alternative build files as experimental and unofficial. Before you start, read README.cmake for the build entry point, confirm the cmake version on your machine is 3.1.0 or later, and check the platform specific readme for the platform you target, since the level of support varies from full to experimental across the port list.

Frequently asked questions

Official sources

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