diff options
| author | Andrew Kelley <andrew@ziglang.org> | 2020-12-11 13:15:58 -0700 |
|---|---|---|
| committer | Andrew Kelley <andrew@ziglang.org> | 2020-12-11 18:34:34 -0500 |
| commit | c4f53d1ef65b7942383471876e02a1bd03d37dd9 (patch) | |
| tree | 93652ba8abf6a20f8529354ec165b8f878254b48 /lib | |
| parent | 5b56f4e48ae01b8b108d063cbc2e45c83d76413d (diff) | |
| download | zig-c4f53d1ef65b7942383471876e02a1bd03d37dd9.tar.gz zig-c4f53d1ef65b7942383471876e02a1bd03d37dd9.zip | |
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
Diffstat (limited to 'lib')
0 files changed, 0 insertions, 0 deletions
