Zig 0.15.2 fails to build in Alpine-3.22.2 based Docker Container due to config.zig not generating properly

[thearchivalone]

Zig Version

0.15.2

Steps to Reproduce and Observed Behavior

Steps to Reproduce

1. Create a Dockerfile with the alpine:3.22.2 image as the base

2. RUN git clone --recursive --depth=1 --branch=0.15.2 https://github.com/ziglang/zig-bootstrap.git (also happens with the zig source, but I like to build with build systems available if I can)

3. RUN apk add --no-cache build-base cmake llvm20 llvm20-dev clang20 clang20-dev lld20 lld20-dev clang20-headers samurai to install build tools and dependencies (samurai is a drop in replacement for ninja that is now becoming a default for Alpine)

4. Set these to force CMake to use Samurai to compile the code:

ENV CMAKE_GENERATOR="Ninja"
ENV ZIG_STATIC="ON"

5. RUN cd zig-bootstrap && sh build x86_64-linux-musl baseline - Setting x86_64 or baseline to native doesn't affect the outcome

6. Wait for Stage 1 to complete and then expect Stage 2 to fail

Following the Build instructions for the zig sources (or using the official Alpine build script as a base for what to pass to Cmake) both have the exact same issue

Observed Behavior

6684.5 [1/20] Building C object CMakeFiles/zig-wasm2c.dir/stage1/wasm2c.c.o
6684.5 [2/20] Building CXX object CMakeFiles/zigcpp.dir/src/zig_clang_cc1as_main.cpp.o
6684.5 [3/20] Building CXX object CMakeFiles/zigcpp.dir/src/zig_clang_cc1_main.cpp.o
6684.5 [4/20] Building CXX object CMakeFiles/zigcpp.dir/src/zig_clang_driver.cpp.o
6684.5 [5/20] Building CXX object CMakeFiles/zigcpp.dir/src/zig_clang.cpp.o
6684.5 [6/20] Building CXX object CMakeFiles/zigcpp.dir/src/zig_llvm-ar.cpp.o
6684.5 [7/20] Building CXX object CMakeFiles/zigcpp.dir/src/zig_llvm.cpp.o
6687.3 [8/20] Linking C executable zig-wasm2c
6687.3 [9/20] Converting /zig-bootstrap/zig/stage1/zig1.wasm to /zig-bootstrap/out/build-zig-host/zig1.c
6690.4 [10/20] Building C object CMakeFiles/zig1.dir/zig1.c.o
6690.4 [11/20] Building C object CMakeFiles/zig1.dir/stage1/wasi.c.o
6702.4 [12/20] Linking CXX static library zigcpp/libzigcpp.a
6872.5 [13/20] Linking C executable zig1
6872.6 [14/20] Running zig1.wasm to produce /zig-bootstrap/out/build-zig-host/compiler_rt.c
6872.6 [15/20] Running zig1.wasm to produce /zig-bootstrap/out/build-zig-host/zig2.c
6879.3 /zig-bootstrap/out/build-zig-host/config.zig:1:1: error: unable to load 'config.zig': FileNotFound
6879.3 src/main.zig:28:31: note: file imported here
6879.3 const build_options = @import("build_options");
6879.3                               ^~~~~~~~~~~~~~~
6879.3 ninja: job failed: cd /zig-bootstrap/zig && /zig-bootstrap/out/build-zig-host/zig1 /zig-bootstrap/zig/lib build-exe -ofmt=c -lc -OReleaseSmall --name zig2 -femit-bin="/zig-bootstrap/out/build-zig-host/zig2.c" -target x86_64-linux --dep build_options --dep aro -Mroot=src/main.zig -Mbuild_options=/cache/deps/zig/out/build-zig-host/config.zig -Maro=lib/compiler/aro/aro.zig
6879.3 ninja: subcommand failed

I've also observed that building Stage 2 tries to use GCC 14 instead of Clang 20 even when explicitly setting Cmake to use Clang. The same issue also occurs using make instead of ninja/samurai (albeit building being much slower)

Expected Behavior

All stages complete without issues and a Stage3 build should be available to use when building Zig, Nim or any other languages that compile with Clang as native C/C++ code

[alexrp]

Do config.h and config.zig actually exist anywhere in the build tree?

I've also observed that building Stage 2 tries to use GCC 14 instead of Clang 20 even when explicitly setting Cmake to use Clang.

That really doesn't sound like a bug on our end? We use add_executable() to compile zig2, just like any other C/C++ executable in CMake. You would need to show how exactly you're telling CMake to use Clang.

[thearchivalone]

Do config.h and config.zig actually exist anywhere in the build tree?

Doesn't seem it but I'd have to look at the cache further. From what I'm observing, neither one seems to generate at all.

I've also observed that building Stage 2 tries to use GCC 14 instead of Clang 20 even when explicitly setting Cmake to use Clang.

That really doesn't sound like a bug on our end? We use add_executable() to compile zig2, just like any other C/C++ executable in CMake. You would need to show how exactly you're telling CMake to use Clang.

ENV CC="clang-20"
ENV CXX="clang++-20"

Also occurs when passing as these environment variables:

ENV CMAKE_C_COMPILER="clang-20"
ENV CMAKE_CXX_COMPILER="clang++-20"

I noticed in the CMakeFiles.txt for zig (in both bootstrap and main source) that it should generate them here: https://github.com/ziglang/zig/blob/feb05a716d1ae105cf0e8f9966b6ade7f32dc680/CMakeLists.txt#L658C1-L665C2

The reason I put the bug in the Zig source repo was because the issue occurs in the zig source and not just the bootstrap. My test happened to be with the bootstrap when I showed it. I also observed the issue building on an old MacBook Air using the homebrew instructions in the zig source readme.

[alexrp]

Do config.h and config.zig actually exist anywhere in the build tree?

Doesn't seem it but I'd have to look at the cache further. From what I'm observing, neither one seems to generate at all.

As far as I can tell, we have dependencies set up as they should be for config.zig. But even if we didn't, I'm pretty sure CMake is supposed to run configure_file() commands at configure time regardless. Maybe you can increase CMake logging verbosity to try to see what's up?

I've also observed that building Stage 2 tries to use GCC 14 instead of Clang 20 even when explicitly setting Cmake to use Clang.

That really doesn't sound like a bug on our end? We use add_executable() to compile zig2, just like any other C/C++ executable in CMake. You would need to show how exactly you're telling CMake to use Clang.

ENV CC="clang20"
ENV CXX="clang20++"

Also occurs when passing as these environment variables:

ENV CMAKE_C_COMPILER="clang20"
ENV CMAKE_CXX_COMPILER="clang20++"

Not sure what's up here either... the build script doesn't muck with any of these variables for the host Zig build. I don't know if CMake is actually supposed to take them from the environment.

[thearchivalone]

Can pass verbosity on it on next rebuild.

By default, CMake can parse those environment variables: https://cmake.org/cmake/help/latest/variable/CMAKE_LANG_COMPILER.html .

Building normal zig on Alpine uses this script: https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/community/zig/APKBUILD

That's also considered an unstable package with 0.14.1 being the latest stable build. If all else fails, most of my current project locally builds successfully with that release outside of Docker.

[alexrp]

By default, CMake can parse those environment variables: https://cmake.org/cmake/help/latest/variable/CMAKE_LANG_COMPILER.html .

I see no indication on that page that CMake might take it from the environment.

[thearchivalone]

Whoops. Wrong links. Here's the defaults for those variables

CC

CXX

[thearchivalone]

May have figured this out. This line right here:

zig-bootstrap/zig/CMakeLists.txt

Line 48 in 1b08653

if(GIT_EXE AND EXISTS "${PROJECT_SOURCE_DIR}/.git")

I was removing the .git directory due to caching the source and not changing versions past the set branch that was checked out. I already set the ZIG_VERSION environment variable.

I removed the call that removes .git and still am testing this out, but that feels like a weird design choice. That would also explain why using either source tree would throw the error since config.zig relies on RESOLVED_ZIG_VERSION being set

[thearchivalone]

Closing this because it's not a bug at all. Just a design choice that doing something nonstandard caused on my end with a PR for a possible improvement.