From c4f53d1ef65b7942383471876e02a1bd03d37dd9 Mon Sep 17 00:00:00 2001 From: Andrew Kelley Date: Fri, 11 Dec 2020 13:15:58 -0700 Subject: fix deadlock with build-exe on an object for windows 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 --- src/Compilation.zig | 5 +++++ 1 file changed, 5 insertions(+) (limited to 'src/Compilation.zig') diff --git a/src/Compilation.zig b/src/Compilation.zig index 3eeaa9ca2a..13ee04765c 100644 --- a/src/Compilation.zig +++ b/src/Compilation.zig @@ -3174,6 +3174,11 @@ pub fn build_crt_file( } pub fn stage1AddLinkLib(comp: *Compilation, lib_name: []const u8) !void { + // Avoid deadlocking on building import libs such as kernel32.lib + // This can happen when the user uses `build-exe foo.obj -lkernel32` and then + // when we create a sub-Compilation for zig libc, it also tries to build kernel32.lib. + if (comp.bin_file.options.is_compiler_rt_or_libc) return; + // This happens when an `extern "foo"` function is referenced by the stage1 backend. // If we haven't seen this library yet and we're targeting Windows, we need to queue up // a work item to produce the DLL import library for this. -- cgit v1.2.3