zig

zig copied to clipboard

Zig Version

0.10.0-dev.4060+61aaef0b0

Steps to Reproduce

On 0.10.0-dev.4060+61aaef0b0 (doesn't happen on 0.10.0-dev.3685+dae7aeb33) I cross-compiled my project on macos, passing -Dtarget=i386-windows-gnu (doesn't happen with -Dtarget=x86_64-windows-gnu) ~~and linked dynamically to SDL2:~~ ~~exe.addObjectFile(try path.join(b.allocator, &[_][]const u8{base_path, "lib/libSDL2.dll.a"}));~~

Expected Behavior

For it to compile and link without error

Actual Behavior

zig build -Dtarget=i386-windows-gnu

LLD Link... lld-link: error: <root>: undefined symbol: _tls_index
error: FileNotFound
/path/zig/lib/zig/std/os.zig:2753:19: 0x10d4fd84e in mkdiratZ (build)
        .EXIST => return error.PathAlreadyExists,
                  ^
/path/zig/lib/zig/std/os.zig:2713:9: 0x10d4e5663 in mkdirat (build)
        return mkdiratZ(dir_fd, &sub_dir_path_c, mode);
        ^
/path/zig/lib/zig/std/fs.zig:1361:9: 0x10d4e551b in makeDir (build)
        try os.mkdirat(self.fd, sub_path, default_new_dir_mode);
        ^
/path/zig/lib/zig/std/os.zig:2753:19: 0x10d4fd84e in mkdiratZ (build)
        .EXIST => return error.PathAlreadyExists,
                  ^
/path/zig/lib/zig/std/os.zig:2713:9: 0x10d4e5663 in mkdirat (build)
        return mkdiratZ(dir_fd, &sub_dir_path_c, mode);
        ^
/path/zig/lib/zig/std/fs.zig:1361:9: 0x10d4e551b in makeDir (build)
        try os.mkdirat(self.fd, sub_path, default_new_dir_mode);
        ^
/path/zig/lib/zig/std/os.zig:1683:23: 0x10d547787 in openatZ (build)
            .NOENT => return error.FileNotFound,
                      ^
/path/zig/lib/zig/std/fs.zig:1110:13: 0x10d52acc8 in openFileZ (build)
            try os.openatZ(self.fd, sub_path, os_flags, 0);
            ^
/path/zig/lib/zig/std/fs.zig:1037:9: 0x10d4f177f in openFile (build)
        return self.openFileZ(&path_c, flags);
        ^
/path/zig/lib/zig/std/fs.zig:2250:24: 0x10d59384b in updateFile (build)
        var src_file = try source_dir.openFile(source_path, .{});
                       ^
/path/zig/lib/zig/std/build.zig:1088:29: 0x10d594902 in updateFile (build)
        const prev_status = try fs.Dir.updateFile(cwd, source_path, cwd, dest_path, .{});
                            ^
/path/zig/lib/zig/std/build.zig:3420:9: 0x10d5981c2 in make (build)
        try builder.updateFile(self.artifact.getOutputSource().getPath(builder), full_dest_path);
        ^
/path/zig/lib/zig/std/build.zig:3655:9: 0x10d4fddc7 in make (build)
        try self.makeFn(self);
        ^
/path/zig/lib/zig/std/build.zig:508:9: 0x10d4e65a9 in makeOneStep (build)
        try s.make();
        ^
/path/zig/lib/zig/std/build.zig:502:17: 0x10d4e650d in makeOneStep (build)
                return err;
                ^
/path/zig/lib/zig/std/build.zig:463:13: 0x10d4e618a in make (build)
            try self.makeOneStep(s);
            ^
/path/zig/lib/zig/build_runner.zig:213:21: 0x10d4e96df in main (build)
            else => return err,
                    ^

Update: even a simple program that doesn't link to anything except libc fails with the same error.

Zig version: 0.10.0-dev.4253+fa9327ac0

Same error on zig-sqlite - build test

Compile C Objects [1/1] sqlite3.c... ar rcs /home/kassane/Downloads/Code/zig-sqlite/zig-cache/o/bf3ff99ef3abbbffae18a10f9ee5cf36/sqlite.lib /home/kassane/Downloads/Code/zig-sqlite/zig-cache/o/c9e997c865096ebaf2f499eba0665592/sqlite3.obj
LLD Link... lld-link -ERRORLIMIT:0 -NOLOGO -DEBUG -STACK:16777216 -MACHINE:X86 -INCLUDE:_tls_index -OUT:/home/kassane/Downloads/Code/zig-sqlite/zig-cache/o/ab926772cd2c769465ca7de4223ad45d/test.exe -IMPLIB:/home/kassane/Downloads/Code/zig-sqlite/zig-cache/o/ab926772cd2c769465ca7de4223ad45d/test.lib /home/kassane/Downloads/Code/zig-sqlite/zig-cache/o/bf3ff99ef3abbbffae18a10f9ee5cf36/sqlite.lib /home/kassane/Downloads/Code/zig-sqlite/zig-cache/o/ab926772cd2c769465ca7de4223ad45d/test.obj -SUBSYSTEM:console -lldmingw -ALTERNATENAME:__image_base__=___ImageBase /home/kassane/.cache/zig/o/d7db52290b714f4ee6b73c6b6c229ecc/crt2.obj /home/kassane/.cache/zig/o/25f2f0e46445a91b9dcd5647c3b2b6b4/mingw32.lib /home/kassane/.cache/zig/o/21586da6086b8e565f1ab1c1362d11e6/mingwex.lib /home/kassane/.cache/zig/o/5d3539b9f9a9cd10c71bdd9c414e3bf5/msvcrt-os.lib /home/kassane/.cache/zig/o/c1944c3cb3a51d9bd49965903abdd0b4/ssp.lib /home/kassane/.cache/zig/o/da6ea5303724671125087537765bd9b5/compiler_rt.lib /home/kassane/.cache/zig/o/628386aae674a2c3098c91f34fb5b290/advapi32.lib /home/kassane/.cache/zig/o/ba67e38636a2518b60120f1fd9d23df9/kernel32.lib /home/kassane/.cache/zig/o/d2a71a0f2849d6daa3c6d0fd2aec0b87/msvcrt.lib /home/kassane/.cache/zig/o/c0eecdf0b27e4883efe64d074df2f871/ntdll.lib /home/kassane/.cache/zig/o/7255daf7cae2399ff56126bd0133ab88/shell32.lib /home/kassane/.cache/zig/o/747decb5c2b4bbac07dde0a8ffbb0e26/user32.lib
lld-link: error: <root>: undefined symbol: _tls_index

Here's a dirty hack until I thoroughly investigate what is up with x86_64 dropping _tls_index symbol, and confirm it doesn't happen on aarch64:

diff --git a/src/Compilation.zig b/src/Compilation.zig
index 958aac5e1..9e62c5f24 100644
--- a/src/Compilation.zig
+++ b/src/Compilation.zig
@@ -2020,7 +2020,9 @@ pub fn create(gpa: Allocator, options: InitOptions) !*Compilation {

             // LLD might drop some symbols as unused during LTO and GCing, therefore,
             // we force mark them for resolution here.
-            try comp.bin_file.options.force_undefined_symbols.put(comp.gpa, "_tls_index", {});
+            if (target.cpu.arch == .x86_64) {
+                try comp.bin_file.options.force_undefined_symbols.put(comp.gpa, "_tls_index", {});
+            }
         }
         // Generate Windows import libs.
         if (target.os.tag == .windows) {

From 0.10.1 release notes:

windows: fix _tls_index not being defined if libc wasn't linked, and fix x86 name mangling

This seems to be fixed?

And if so, shouldn't there be a windows-i386 release of Zig 0.10.1?

i386-windows regressed during the 0.10.x release cycle. The target is fixed in the 0.11.x release cycle. There will be no binaries provided for i386-windows for 0.10.x releases.

This issue is fixed in master branch; closing.