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

1 files changed, 5 insertions, 0 deletions

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.