-
-
Notifications
You must be signed in to change notification settings - Fork 2.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Zig 0.14.0 Build: unable to open '': FileNotFound #23120
Comments
Oh weirdly, with a clean cache I get a different error trace after which, if I run it again I get the error trace above.
|
I encountered the same issue with very similar dependencies (vulkan and zglfw). I managed to work around it by bumping my dependencies to use the new hash format instead. |
I'm hitting it in https://github.com/allyourcodebase/zlib which only has the one dependency, even with the dependency updated to the new hash format. this diff fixes the problem: --- a/lib/std/Build/Step/InstallArtifact.zig
+++ b/lib/std/Build/Step/InstallArtifact.zig
@@ -189,9 +189,9 @@ fn make(step: *Step, options: Step.MakeOptions) !void {
const src_dir_path = dir.source.getPath3(b, step);
const full_h_prefix = b.getInstallPath(h_dir, dir.dest_rel_path);
- var src_dir = src_dir_path.root_dir.handle.openDir(src_dir_path.sub_path, .{ .iterate = true }) catch |err| {
- return step.fail("unable to open source directory '{s}': {s}", .{
- src_dir_path.sub_path, @errorName(err),
+ var src_dir = src_dir_path.root_dir.handle.openDir(src_dir_path.subPathOrDot(), .{ .iterate = true }) catch |err| {
+ return step.fail("unable to open source directory '{}': {s}", .{
+ src_dir_path, @errorName(err),
});
};
defer src_dir.close(); which looks like a reasonable change to make regardless, but it does not explain why it worked before. |
That's interesting, I made that change and now it only happens in ~ 1 out of 5 builds rather than every time. |
43f73af looks relevant but that was a long time ago |
I can reproduce the problem with 6b6c1b1 which is before the new hash change. |
Oh, interesting, I realized that for zglfw I pointed to a local copy (via .path) while experimenting so might also have been what fixed it. If it helps I know I had no issues on 6fe1993 before updating to v0.14.0. |
So I think this fixed a related issue, but I'm still seeing the original problem I had when I checkout When I use a debug build of zig, I see this issue: ![]() Seems like it's interpolating uninitialized memory when it tries to template in I'm not super familiar with this code, but I sat down to debug it a bit. I think the issue is that my transitive dependency graph includes two copies of the exact same dependency on I made a PR for the patch that seems to fix it for me locally here #23172. |
Zig Version
0.14.0
Steps to Reproduce and Observed Behavior
rm -rf ~/.cache/zig .zig-cache zig-out
zig build
zig build
The second build onwards seems to have this is issue:
It seems like it's failing to create the build graph at all since I'm unable to even use
zig build --help
.Occasionally if I keep deleting the cache and rerunning the build I can get it to segfault as well. I just did a dev build of zig
0.14.0
tag and this is the backtrace in LLDBAnd here's the zig error trace if I let it run:
Expected Behavior
zig build
should work after cache is built.The text was updated successfully, but these errors were encountered: