glfw-rs: Rust bindings for GLFW with a feature set you control

What the crate is, and what it deliberately is not

glfw-rs is a set of GLFW bindings and an idiomatic wrapper for Rust, published on crates.io as glfw. The crate description in the manifest is GLFW3 bindings and idiomatic wrapper for Rust, with keywords for windowing, opengl and vulkan, and it is Apache-2.0 licensed.

The scope is worth being precise about, because GLFW itself is a small library and this crate does not expand it. GLFW handles window creation, input events and the OpenGL context. It is not a renderer, not a scene graph and not an asset pipeline. The Rust wrapper gives you the same surface in safe-ish Rust, with types like Window, Context and WindowEvent, and the example in the documentation shows the whole shape of a program in about thirty lines:

extern crate glfw;

use glfw::{Action, Context, Key};

fn main() {
    let mut glfw = glfw::init(glfw::fail_on_errors).unwrap();

    let (mut window, events) = glfw.create_window(300, 300, "Hello this is window", glfw::WindowMode::Windowed)
        .expect("Failed to create GLFW window.");

    window.set_key_polling(true);
    window.make_current();

    while !window.should_close() {
        glfw.poll_events();
        for (_, event) in glfw::flush_messages(&events) {
            handle_window_event(&mut window, event);
        }
    }
}

The event loop is the recognisable part. init with fail_on_errors means a failed initialisation is an error rather than a silent no-op, create_window returns the window and the event channel together, and flush_messages drains the events and hands them to a handler that matches on WindowEvent. The Escape key closes the window, which is the whole of the input handling in the example.

There is a second mode as well, unbuffered events, and the examples directory shows the rest of the surface: cursor handling, cursor icons, fullscreen, monitors, multiple windows, render tasks, a Vulkan example, a raw window handle example, clipboard, window icons and title handling, defaults, error handling, modes and version information.

Two projects that use it are named in the documentation, kiss3d and q3, along with rsmc and zoc.

The features block is the real configuration surface

The Cargo.toml in the repository is where the engineering decisions live, and the features list is long enough to be worth reading in full.

The default feature set is all, which pulls in image, vulkan, log, wayland, x11 and raw-window-handle-v0-6, plus prebuilt-libs. So by default you get a C library that is not compiled from source, both windowing backends, Vulkan support, the image and log integrations, and the v0.6 raw-window-handle.

The individual features are the ones that matter for a build. src-build compiles the glfw library from source, dynamic-link links it dynamically instead, prebuilt-libs uses the prebuilt binaries, and vulkan, wayland and x11 each turn on the matching glfw-sys feature. There are also native-handles, which exposes the underlying platform handles, and the two raw-window-handle features, raw-window-handle-v0-6 and raw-window-handle-v0-5, which are mutually exclusive by construction because each enables a different optional dependency and the native-handles feature.

The dependency list explains the platform story. glfw-sys is the raw FFI layer, pulled with default-features turned off and the native-gl and native-egl features enabled. The windowing backends are features of glfw-sys rather than separate crates, so choosing x11 or wayland changes what glfw-sys compiles rather than what you depend on. The macOS target adds objc2, and the Windows target adds winapi with the libloaderapi feature, which is what allows the dynamic loading path on Windows.

The optional image, log and serde dependencies are the integrations a game or tool usually wants: image for window icons, log for tracing, serde for serialising GLFW structures. The dev dependencies include ash for the Vulkan example and log again for the tests.

The docs.rs metadata shows what the maintainers consider the widest configuration worth documenting, with features set to all, no-default-features turned on, and three targets built: x86_64-unknown-linux-gnu, x86_64-apple-darwin and x86_64-pc-windows-msvc.

Getting GLFW itself onto the machine, and the Windows exception

The prerequisite is GLFW 3.x, compiled and installed. The documentation suggests a package manager, and gives the macOS example as brew install glfw3, with a note that you may need to run brew tap homebrew/versions first. Otherwise you build the library from the source on the GLFW website.

There is a Linux-specific wrinkle with CMake. If you compile GLFW with CMake on Linux, the documentation says you have to supply the -DCMAKE_C_FLAGS=-fPIC argument, which is the usual requirement for building a shared library that can be linked into something else. If GLFW is not installed into your PATH, you point the build at the directory holding the library binaries with an environment variable:

GLFW_LIB_DIR=path/to/glfw/lib/directory make

Adding the crate to a project is the usual Cargo dependency block:

[dependencies.glfw]
version = "*"

Windows is the exception the documentation calls out. By default glfw-rs will try to compile the glfw library, and on Windows that build probably does not work, so the way to link to a custom build or to skip the compile is to turn off default features:

[dependencies.glfw]
version = "*"
default-features = false

There is also a version compatibility note for raw-window-handle, which is how a Rust window handle is shared with graphics stacks such as winit or wgpu. The default is raw-window-handle at v0.6.0, and if your project depends on v0.5.0 there is a feature for it:

glfw = { version = 0.56.0 , default-features = false, features = ["with-window-handle-v0-5"] }

That last block belongs in Cargo.toml rather than a shell, and it is the one example in the documentation that mixes a version, a features list and the disablement of defaults in a single line.

The OpenGL and Vulkan conflict, and the window hint that avoids it

One operational problem deserves its own section, because it produces crashes rather than compile errors.

GLFW uses OpenGL, and in certain circumstances that conflicts with the new handle that a graphical API is also trying to use. The result is a crash. The documented fix is a window hint set before the window is created:

glfw.window_hint(WindowHint::ClientApi(ClientApiHint::NoApi));

The trade is explicit in the documentation. If you use this hint, you cannot use certain built-in functions, specifically window.swap_buffers(), window.make_current() and glfw.set_swap_interval(). The reasoning given is that the graphical API should provide equivalents.

That is the shape of using this crate with a modern renderer. GLFW is there for the window and the event loop, and the rendering API owns the surface, the swap chain and the present call. The Vulkan example in the examples directory is the concrete case, and it pairs with the ash dev dependency, which is the Rust Vulkan bindings.

For a plain OpenGL tool the arrangement is simpler: GLFW creates the context, make_current and swap_buffers work as expected, and the crate stays a thin layer over what GLFW already does.

Where glfw-rs is the wrong choice

The first limitation is the native build in the dependency tree. The crate pulls in glfw-sys, which is a Rust binding to a C library, and depending on the features you choose, that C library is compiled from source, linked dynamically or taken from a prebuilt binary. A project that has a policy against native code in its dependencies, or a reproducible build that must not invoke a C compiler, has to turn default features off and supply the library itself. That is a supported configuration, and it is also extra work.

The second is the age of the surrounding ecosystem. The crate uses edition 2021 with a minimum Rust version of 1.56, and it depends on raw-window-handle 0.5 and 0.6 rather than the current line. The raw-window-handle situation in particular is a compatibility burden: if the rest of your application uses a newer version of that crate, you will be resolving two versions of it, and the documentation tells you to select the older one explicitly.

The third is that this is bindings, not an engine. There is no renderer, no scene graph, no asset pipeline, no audio, no input mapping, no text rendering. The example program is thirty lines because it does one thing. A team that wants to build a game will end up assembling a stack of crates, and the projects the documentation lists as users, kiss3d and q3, are exactly that: engines and renderers built on top of this crate rather than replacements for it.

The fourth is the maintenance story. The repository publishes no GitHub releases, so there is no tag history to read, and the support section points at an IRC channel on irc.mozilla.org, which is a channel nobody uses any more, alongside GitHub issues. The last push was on 2026-09-23, and the crate version in the manifest is 0.63.0, so the code is being maintained, but the signalling about how to get help and what changed is thin.

The fifth is windowing-backend coverage. X11 and Wayland are both features, but they are features of glfw-sys, so what works on your platform depends on what that upstream crate supports there. If your target is a Wayland-only session on a distribution whose compositor is strict about the client protocol, that is a place to check before committing.

Editorial conclusion

glfw-rs fits a Rust developer who wants a thin, readable wrapper over GLFW 3 rather than a full engine, since the API is a direct translation with an idiomatic surface, the feature list lets you choose exactly which native pieces get built, and the crate is Apache-2.0 licensed with the source in the repository. It is the wrong choice if your build pipeline cannot compile or link a C library, if you need a maintained engine with rendering, input and audio already handled, or if the OpenGL and Vulkan paths you need are not covered by the available backends. Before adopting it, decide whether the prebuilt-libs or src-build feature suits your platform, check the raw-window-handle version your windowing stack already uses, and note that the last push was on 2026-09-23 while the repository publishes no tagged releases, so the crate version on crates.io is the thing to pin.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. PistonDevelopers/glfw-rs on GitHub
4. README