# Issue with build.zig and Raylib

**URL:** <https://ziggit.dev/t/issue-with-build-zig-and-raylib/18226>\
**Category:** Help\
**Tags:** build-system, raylib\
**Created:** [November 5, 2026, 1:45pm UTC](https://ziggit.dev/t/issue-with-build-zig-and-raylib/18226 "2026-11-05T13:45:21Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![Smoeboe](https://ziggit.dev/user_avatar/ziggit.dev/smoeboe/32/10529_2.png) [@Smoeboe](https://ziggit.dev/u/Smoeboe)\
**Post date:** [November 5, 2026, 1:45pm UTC](https://ziggit.dev/t/issue-with-build-zig-and-raylib/18226/1 "2026-11-05T13:45:21Z")

</div>

Hi. I’m having issues building a zig project after trying to install Raylib.

(Background: I’m new to zig, but have done majority of the ziglings examples, started porting some of my smaller projects to mess about, and even started work on a WASM plugin for traefik)

I’m now trying to follow a little course on creating space invaders for zig to learn a bit more, but I’m stuck on building.

```zig
$ zig version                                                                                                                                             
0.18.0-dev.860+8e8cf3835

```

Here is my build.zig:

```zig
const std = @import("std");

// Although this function looks imperative, it does not perform the build
// directly and instead it mutates the build graph (`b`) that will be then
// executed by an external runner. The functions in `std.Build` implement a DSL
// for defining build steps and express dependencies between them, allowing the
// build runner to parallelize the build automatically (and the cache system to
// know when a step doesn't need to be re-run).
pub fn build(b: *std.Build) void {
    // Standard target options allow the person running `zig build` to choose
    // what target to build for. Here we do not override the defaults, which
    // means any target is allowed, and the default is native. Other options
    // for restricting supported target set are available.
    const target = b.standardTargetOptions(.{});
    // Standard optimization options allow the person running `zig build` to select
    // between debug, safe, fast, and small. Here we do not
    // set a preferred release mode, allowing the user to decide how to optimize.
    const optimize = b.standardOptimizeOption(.{});
    // It's also possible to define more custom flags to toggle optional features
    // of this build script using `b.option()`. All defined flags (including
    // target and optimize options) will be listed when running `zig build --help`
    // in this directory.

    // RAYLIB!
    const raylib_dep = b.dependency("raylib_zig", .{
        .target = target,
        .optimize = optimize,
    });
    const raylib = raylib_dep.module("raylib"); // main raylib module
    const raygui = raylib_dep.module("raygui"); // raygui module
    const raylib_artifact = raylib_dep.artifact("raylib"); // raylib C library

    // This creates a module, which represents a collection of source files alongside
    // some compilation options, such as optimization mode and linked system libraries.
    // Zig modules are the preferred way of making Zig code available to consumers.
    // addModule defines a module that we intend to make available for importing
    // to our consumers. We must give it a name because a Zig package can expose
    // multiple modules and consumers will need to be able to specify which
    // module they want to access.
    const mod = b.addModule("spaceinvaders", .{
        // The root source file is the "entry point" of this module. Users of
        // this module will only be able to access public declarations contained
        // in this file, which means that if you have declarations that you
        // intend to expose to consumers that were defined in other files part
        // of this module, you will have to make sure to re-export them from
        // the root file.
        .root_source_file = b.path("src/root.zig"),
        // Later on we'll use this module as the root module of a test executable
        // which requires us to specify a target.
        .target = target,
    });

    // Here we define an executable. An executable needs to have a root module
    // which needs to expose a `main` function. While we could add a main function
    // to the module defined above, it's sometimes preferable to split business
    // logic and the CLI into two separate modules.
    //
    // If your goal is to create a Zig library for others to use, consider if
    // it might benefit from also exposing a CLI tool. A parser library for a
    // data serialization format could also bundle a CLI syntax checker, for example.
    //
    // If instead your goal is to create an executable, consider if users might
    // be interested in also being able to embed the core functionality of your
    // program in their own executable in order to avoid the overhead involved in
    // subprocessing your CLI tool.
    //
    // If neither case applies to you, feel free to delete the declaration you
    // don't need and to put everything under a single module.
    const exe = b.addExecutable(.{
        .name = "spaceinvaders",
        .root_module = b.createModule(.{
            // b.createModule defines a new module just like b.addModule but,
            // unlike b.addModule, it does not expose the module to consumers of
            // this package, which is why in this case we don't have to give it a name.
            .root_source_file = b.path("src/main.zig"),
            // Target and optimization levels must be explicitly wired in when
            // defining an executable or library (in the root module), and you
            // can also hardcode a specific target for an executable or library
            // definition if desireable (e.g. firmware for embedded devices).
            .target = target,
            .optimize = optimize,
            // List of modules available for import in source files part of the
            // root module.
            .imports = &.{
                // Here "spaceinvaders" is the name you will use in your source code to
                // import this module (e.g. `@import("spaceinvaders")`). The name is
                // repeated because you are allowed to rename your imports, which
                // can be extremely useful in case of collisions (which can happen
                // importing modules from different packages).
                .{ .name = "spaceinvaders", .module = mod },
                .{ .name = "raylib", .module = raylib },
            },
        }),
    });

    // This declares intent for the executable to be installed into the
    // install prefix when running `zig build` (i.e. when executing the default
    // step). By default the install prefix is `zig-out/` but can be overridden
    // by passing `--prefix` or `-p`.
    b.installArtifact(exe);

    exe.root_module.linkLibrary(raylib_artifact);
    exe.root_module.addImport("raylib", raylib);
    exe.root_module.addImport("raygui", raygui);

    // This creates a top level step. Top level steps have a name and can be
    // invoked by name when running `zig build` (e.g. `zig build run`).
    // This will evaluate the `run` step rather than the default step.
    // For a top level step to actually do something, it must depend on other
    // steps (e.g. a Run step, as we will see in a moment).
    const run_step = b.step("run", "Run the app");

    // This creates a RunArtifact step in the build graph. A RunArtifact step
    // invokes an executable compiled by Zig. Steps will only be executed by the
    // runner if invoked directly by the user (in the case of top level steps)
    // or if another step depends on it, so it's up to you to define when and
    // how this Run step will be executed. In our case we want to run it when
    // the user runs `zig build run`, so we create a dependency link.
    const run_cmd = b.addRunArtifact(exe);
    run_step.dependOn(&run_cmd.step);

    // By making the run step depend on the default step, it will be run from the
    // installation directory rather than directly from within the cache directory.
    run_cmd.step.dependOn(b.getInstallStep());

    // This allows the user to pass arguments to the application in the build
    // command itself, like this: `zig build run -- arg1 arg2 etc`
    run_cmd.addPassthruArgs();

    // Creates an executable that will run `test` blocks from the provided module.
    // Here `mod` needs to define a target, which is why earlier we made sure to
    // set the releative field.
    const mod_tests = b.addTest(.{
        .root_module = mod,
    });

    // A run step that will run the test executable.
    const run_mod_tests = b.addRunArtifact(mod_tests);

    // Creates an executable that will run `test` blocks from the executable's
    // root module. Note that test executables only test one module at a time,
    // hence why we have to create two separate ones.
    const exe_tests = b.addTest(.{
        .root_module = exe.root_module,
    });

    // A run step that will run the second test executable.
    const run_exe_tests = b.addRunArtifact(exe_tests);

    // A top level step for running all tests. dependOn can be called multiple
    // times and since the two run steps do not depend on one another, this will
    // make the two of them run in parallel.
    const test_step = b.step("test", "Run tests");
    test_step.dependOn(&run_mod_tests.step);
    test_step.dependOn(&run_exe_tests.step);

    // Just like flags, top level steps are also listed in the `--help` menu.
    //
    // The Zig build system is entirely implemented in userland, which means
    // that it cannot hook into private compiler APIs. All compilation work
    // orchestrated by the build system will result in other Zig compiler
    // subcommands being invoked with the right flags defined. You can observe
    // these invocations when one fails (or you pass a flag to increase
    // verbosity) to validate assumptions and diagnose problems.
    //
    // Lastly, the Zig build system is relatively simple and self-contained,
    // and reading its source code will allow you to master it.
}

```

here is a snippet for raylib in my build.zig.zon:

```zig
    .dependencies = .{
        .raylib_zig = .{
            .url = "git+https://www.github.com/raylib-zig/raylib-zig?ref=devel#28bbe30112f605da918db00eff53a75ce1aa9180",
            .hash = "raylib_zig-6.2.0-KE8RELGmBQDX1v1DqBN57pNxJ-b-MIa1S-M7NXT9Eplr",
        },
    },

```

And here is the build error I get:

```zig
$ zig build
zig-pkg/raylib_zig-6.2.0-KE8RELGmBQDX1v1DqBN57pNxJ-b-MIa1S-M7NXT9Eplr/build.zig:84:17: error: no field named 'needed_lazy_dependencies' in struct 'Build.Graph'
    if (b.graph.needed_lazy_dependencies.count() != 0) b.serializeConfigurationExiting();
                ^ ~~~~~~~~~~~~~~~~~~~~~~~
/snap/zig/17212/lib/std/Build.zig:75:19: note: struct declared here
pub const Graph = struct {
                  ^ ~~~~~
referenced by:
    runPackageScript [inlined]: /snap/zig/17212/lib/std/Build.zig:2221:50
    run: /snap/zig/17212/lib/std/Build.zig:2074:40
    9 reference(s) hidden; use '-freference-trace=11' to see all references

```

---

<div class="post-metadata">

**Author:** ![Chikushu](https://ziggit.dev/user_avatar/ziggit.dev/chikushu/32/10535_2.png) [@Chikushu](https://ziggit.dev/u/Chikushu)\
**Post date:** [November 5, 2026, 2:07pm UTC](https://ziggit.dev/t/issue-with-build-zig-and-raylib/18226/2 "2026-11-05T14:07:52Z")

</div>

On master `std.Build` reworked lazy dependencies: [std.Build: lazy dependencies can associate with steps · 2c18bccf44 - ziglang/zig - Codeberg.org](https://codeberg.org/ziglang/zig/commit/2c18bccf4428a6e23ed5c5572243337a560af9b5) .

The quickest way is to use zig 0.17.0 to resolve the issue. If you really want to use zig master, you will have to fix `raylib_zig` to use `unlazy_deps` instead of `needed_lazy_dependencies`. On line 84 in the `build.zig` of `raylib_zig` is the line that you’d need to fix.

I checked `raylib_zig` and the supported zig version is 0.17.0, I would recommend using 0.17.0 if you want to use this library.

---

<div class="post-metadata">

**Author:** ![Smoeboe](https://ziggit.dev/user_avatar/ziggit.dev/smoeboe/32/10529_2.png) [@Smoeboe](https://ziggit.dev/u/Smoeboe)\
**Post date:** [November 5, 2026, 2:10pm UTC](https://ziggit.dev/t/issue-with-build-zig-and-raylib/18226/3 "2026-11-05T14:10:53Z")

</div>

Ah thx. I guess that the problem with trying to stay bleeding edge. Maybe I’ll do a PR on raylib\_zig, if they are interested.

I’m trying to stay on latest as much as possible for now, so I guess many third party libs will have issues like this for the time being.

---

<div class="post-metadata">

**Author:** ![yinameah](https://ziggit.dev/user_avatar/ziggit.dev/yinameah/32/8453_2.png) [@yinameah](https://ziggit.dev/u/yinameah)\
**Post date:** [November 5, 2026, 3:05pm UTC](https://ziggit.dev/t/issue-with-build-zig-and-raylib/18226/4 "2026-11-05T15:05:05Z")

</div>

I’ll spare the effort of proposing PR to Raylib.

They prefer to stick to tagged releases.  
And there is a bunch of people into zig contributing to Raylib so they got you covered when new release there is.

(But as an exercise, for having done that in the 0.17 cycle, maintaining some package fork in sync with master is cool if you want to follow the dev process)

---

<div class="post-metadata">

**Author:** ![Smoeboe](https://ziggit.dev/user_avatar/ziggit.dev/smoeboe/32/10529_2.png) [@Smoeboe](https://ziggit.dev/u/Smoeboe)\
**Post date:** [November 5, 2026, 4:37pm UTC](https://ziggit.dev/t/issue-with-build-zig-and-raylib/18226/5 "2026-11-05T16:37:10Z")

</div>

yeah that was going to my first step anyway 😉