ziglang
`mingw`: Update MinGW-w64 to 38c8142f660b6ba11e7c408f2de1e9f8bfaf839e.
I can't reproduce the aarch64-macos failures locally even with
diff --git a/test/standalone/coff_dwarf/build.zig b/test/standalone/coff_dwarf/build.zig
index 53425db8d3..891369f043 100644
--- a/test/standalone/coff_dwarf/build.zig
+++ b/test/standalone/coff_dwarf/build.zig
@@ -10,7 +10,7 @@ pub fn build(b: *std.Build) void {
const target = if (builtin.os.tag == .windows)
b.standardTargetOptions(.{})
else
- b.resolveTargetQuery(.{ .os_tag = .windows });
+ b.resolveTargetQuery(.{ .cpu_arch = .aarch64, .os_tag = .windows });
const exe = b.addExecutable(.{
.name = "main",
and zig build test in test/standalone/coff_dwarf.
:shrug:
@mstorsjo does this error when building a DLL ring a bell for you?
error: lld-link: unable to automatically import from _fpreset with relocation type IMAGE_REL_ARM64_BRANCH26 in libmingw32.lib(tlsthrd.obj)
When building an EXE, I also see:
lld-link: error: unable to automatically import from _fpreset with relocation type IMAGE_REL_ARM64_BRANCH26 in /home/alexrp/.cache/zig/o/0f67c7ef8da3bf60c9e8ad52eff05c96/crt2.obj
lld-link: error: unable to automatically import from _fpreset with relocation type IMAGE_REL_ARM64_BRANCH26 in libmingw32.lib(crt_handler.obj)
lld-link: error: unable to automatically import from _fpreset with relocation type IMAGE_REL_ARM64_BRANCH26 in libmingw32.lib(tlsthrd.obj)
I'm not sure if this is an artifact of the way we build MinGW-w64 in Zig, or if it's an actual regression of sorts from the ~recent related changes upstream.
I tried changing all uses of _fpreset to:
extern void (* __MINGW_IMP_SYMBOL(_fpreset))(void);
// ...
(* __MINGW_IMP_SYMBOL(_fpreset))();
That links for all Windows targets, but of course does the wrong thing for x86 where we do in fact want _fpreset from CRT_fp10.c. I can make it conditional on __i386__/__x86_64__, but it seems like there should be a better way? :thinking:
@mstorsjo does this error when building a DLL ring a bell for you?
error: lld-link: unable to automatically import from _fpreset with relocation type IMAGE_REL_ARM64_BRANCH26 in libmingw32.lib(tlsthrd.obj)
Not offhand, no.
When building an EXE, I also see:
lld-link: error: unable to automatically import from _fpreset with relocation type IMAGE_REL_ARM64_BRANCH26 in /home/alexrp/.cache/zig/o/0f67c7ef8da3bf60c9e8ad52eff05c96/crt2.obj lld-link: error: unable to automatically import from _fpreset with relocation type IMAGE_REL_ARM64_BRANCH26 in libmingw32.lib(crt_handler.obj) lld-link: error: unable to automatically import from _fpreset with relocation type IMAGE_REL_ARM64_BRANCH26 in libmingw32.lib(tlsthrd.obj)I'm not sure if this is an artifact of the way we build MinGW-w64 in Zig
Yes, this is usually the cause.
The error "unable to automatically import" may be misleading for your case; it means that the generated code referenced the symbol _fpreset, but at link time it only found __imp__fpreset, not _fpreset. If this would be an imported data symbol, then such symbols should be referenced with a relocation that allows automatic import. But this is not a data symbol, it is a function. So in other words, this says that the function symbol _fpreset is missing in your build of mingw-w64-crt - which is very plausibly cause by the way Zig builds mingw-w64.
For disambiguation, I recommend checking e.g. https://github.com/mstorsjo/llvm-mingw/releases/nightly; if we download https://github.com/mstorsjo/llvm-mingw/releases/download/nightly/llvm-mingw-nightly-ucrt-ubuntu-22.04-x86_64.tar.xz, unpack it and run llvm-nm --defined-only --print-file-name *.a | grep _fpreset in the aarch64-w64-mingw32/lib directory, we find this:
libmsvcrt-os.a:msvcrt.dll: 00000000 T __imp__fpreset
libmsvcrt-os.a:msvcrt.dll: 00000000 T _fpreset
libmsvcrt-os.a:msvcrt.dll: 00000000 W __imp_fpreset
libmsvcrt.a:api-ms-win-crt-runtime-l1-1-0.dll: 00000000 T __imp__fpreset
libmsvcrt.a:api-ms-win-crt-runtime-l1-1-0.dll: 00000000 T _fpreset
libucrt.a:api-ms-win-crt-runtime-l1-1-0.dll: 00000000 T __imp__fpreset
libucrt.a:api-ms-win-crt-runtime-l1-1-0.dll: 00000000 T _fpreset
libucrtapp.a:api-ms-win-crt-runtime-l1-1-0.dll: 00000000 T __imp__fpreset
libucrtapp.a:api-ms-win-crt-runtime-l1-1-0.dll: 00000000 T _fpreset
libucrtbase.a:ucrtbase.dll: 00000000 T __imp__fpreset
libucrtbase.a:ucrtbase.dll: 00000000 T _fpreset
libucrtbase.a:ucrtbase.dll: 00000000 W __imp_fpreset
libucrtbased.a:ucrtbased.dll: 00000000 T __imp__fpreset
libucrtbased.a:ucrtbased.dll: 00000000 T _fpreset
libucrtbased.a:ucrtbased.dll: 00000000 W __imp_fpreset
So it should be provided by libucrt.a and libmsvcrt.a and all the others.
For libucrt.a, the export is provided here: https://github.com/mingw-w64/mingw-w64/blob/v13.0.0/mingw-w64-crt/lib-common/api-ms-win-crt-runtime-l1-1-0.def.in#L47 (It is defined in a similar way in msvcrt.def.in too, for that matter.)
Note that the DATA flag (which determines if it provides the symbol foo in addition to __imp_foo) is guarded by F_LD80. This define was added here: https://github.com/mingw-w64/mingw-w64/commit/87ec8e6c5a62451825f1e87fb47a0e95041fa01f
However to make conditions like this work properly when preprocessing the def files, there was this change made as well: https://github.com/mingw-w64/mingw-w64/commit/33d8fc4ce32fdc9fa1a0486c2f96f08252c6c841
So you probably need to mirror this change in the Zig build system, and make sure that the def files are preprocessed with defines that match the target, so that any condition like defined(__aarch64__) or __SIZEOF_LONG_DOUBLE__ == __SIZEOF_DOUBLE__ get evaluated correctly.
Thanks for looking into this! It hadn't occurred to me that the preprocessing step might be the problem, but that seems to be it. Looking at the generated .def file, it has _fpreset DATA, and the resulting import library doesn't define _fpreset, only __imp__fpreset.
We do run the files through the Aro preprocessor here:
https://github.com/ziglang/zig/blob/6810ffa424fccae0ecbf2f9e3db80069d8e7543b/src/libs/mingw.zig#L297-L338
So it seems like the problem in this specific case is that Aro doesn't define __SIZEOF_LONG_DOUBLE__ correctly for (aarch64,thumb)-windows. (cc @Vexu)
