c4f53d1ef6
The steps to repro this issue are: zig build-obj hello.zig -target x86_64-windows-msvc zig build-exe hello.obj -target x86_64-windows-msvc --subsystem console -lkernel32 -lntdll What was happening is that the main Compilation added a work item to produce kernel32.lib. Then it added a sub-Compilation to build zig's libc, which ended up calling a function with extern "kernel32", which caused the sub-Compilation to also try to produce kernel32.lib. The main Compilation and sub-Compilation do not coordinate about the set of import libraries that they will be trying to build, so this caused a deadlock. This commit solves the problem by disabling the extern "foo" feature from working when building compiler_rt or libc. Zig's linker code is now responsible for putting the appropriate import libs on the linker line, if any for compiler_rt and libc. Related: #5825
25 lines
677 B
Zig
25 lines
677 B
Zig
const Builder = @import("std").build.Builder;
|
|
|
|
pub fn build(b: *Builder) void {
|
|
const target = .{
|
|
.cpu_arch = .x86_64,
|
|
.os_tag = .windows,
|
|
.abi = .msvc,
|
|
};
|
|
const mode = b.standardReleaseOptions();
|
|
const obj = b.addObject("issue_5825", "main.zig");
|
|
obj.setTarget(target);
|
|
obj.setBuildMode(mode);
|
|
|
|
const exe = b.addExecutable("issue_5825", null);
|
|
exe.subsystem = .Console;
|
|
exe.linkSystemLibrary("kernel32");
|
|
exe.linkSystemLibrary("ntdll");
|
|
exe.setTarget(target);
|
|
exe.setBuildMode(mode);
|
|
exe.addObject(obj);
|
|
|
|
const test_step = b.step("test", "Test the program");
|
|
test_step.dependOn(&exe.step);
|
|
}
|