`windows-gnu`: Adhere to MinGW convention for build outputs #22415

Doekin · 2025-01-05T05:59:27Z

This PR potentially addresses issues #20039, #21103, and #16811.

Background

As outlined in #20039, when attempting to link a library named foo, the default search paths are foo.dll, foo.lib, and libfoo.a. However, the conventional DLL name format in MinGW is libfoo.dll and libfoo.dll.a. This mismatch can cause issues when working with build tools like CMake. This PR aims to resolve the inconsistency and improve compatibility.

Changes

Updated fn fileExt(of: ObjectFormat, arch: Cpu.Arch) in std.Target.ObjectFormat to fn fileExt(of: ObjectFormat, abi: Abi, arch: Cpu.Arch).
Changed default output names for MinGW targets:
- Object files: .obj → .o
- Static libraries: foo.lib → libfoo.a
- Shared libraries: foo.dll → libfoo.dll, import libraries: foo.lib → libfoo.dll.a
- Debug symbols: .pdb → DWARF format.
Adjusted library search paths to reflect the new output names.
Default behavior updated to not emit import libraries for executables or shared libraries when targeting the GNU ABI.
Added support for the -mwindows linker flag (complements zig cc: support --subsystem linker flag #11396).

Example

GCC/Clang generate a 66KiB file when creating a simple shared library. Previously, zig 0.13 would generate three files: a.exe (144.5 KiB), a.pdb (872.0 KiB), and foo.lib (1.2 KiB). After these changes, zig cc generates a single file: a.exe (874.0 KiB).

Additionally, when attempting to link to a non-existent library, the error message now reflects the updated search order:

Before

$ zig cc -target x86_64-windows-gnu main.c -lfoo -L.
error: unable to find dynamic system library 'foo' using strategy 'paths_first'. searched paths:
  .\foo.dll
  .\foo.lib
  .\libfoo.a

After

$ zig cc -target x86_64-windows-gnu main.c -lfoo -L.
error: unable to find dynamic system library 'foo' using strategy 'paths_first'. searched paths:
  .\libfoo.dll
  .\libfoo.dll.a
  .\foo.dll
  .\libfoo.a
  .\foo.lib

alexrp · 2025-01-05T06:14:13Z

Disabled default import library emission in zig cc mode (still enabled by default in zig build).

This is the only part of this PR for which the rationale is not immediately obvious to me. Can you elaborate on this point?

Doekin · 2025-01-05T06:21:32Z

Thank you for your feedback.

When using zig cc as a replacement for LLVM-MinGW, I noticed that main.lib was generated alongside HelloQt.exe. Since GCC and Clang do not emit import libraries by default, I felt it would be more consistent to align zig cc with this behavior.

alexrp · 2025-01-05T16:55:40Z

Ok, that makes sense. I would suggest including that rationale in the commit message.

lib/std/Target.zig

src/main.zig

alexrp · 2025-01-07T00:47:14Z

src/Compilation/Config.zig

@@ -444,9 +444,10 @@ pub fn resolve(options: Options) ResolveError!Config {
        if (options.debug_format) |x| break :b x;
        break :b switch (target.ofmt) {
            .elf, .goff, .macho, .wasm, .xcoff => .{ .dwarf = .@"32" },
-            .coff => .code_view,
+            .coff => if (target.abi.isGnu()) .{ .dwarf = .@"32" } else .code_view,


This change -- DWARF by default (i.e. embedded into the binary; no PDB) for MinGW -- is probably the only controversial change in this PR. I don't personally have a problem with it since you can still opt into getting a PDB, but we should probably think carefully about this change nonetheless.

cc @squeek502 @andrewrk for thoughts, maybe others?

I don't feel like I know enough about why MinGW made this choice to give any useful feedback here.

I have a more general question, though (and this is also coming from ignorance, this is not necessarily intended as a criticism of these changes): is the stuff in this PR related to 'targeting the MinGW ABI' or is it more related to 'emulating the MinGW toolchain'? If it's the latter, is that something that Zig-the-compiler is/should be interested in? Would it make any sense to limit any 'emulating the MinGW toolchain' to zig cc, specifically?

Native debuggers on Windows all expect PDBs, I think this change would hurt debuggability there - it would mean users would have to always specify a non-default option to use the default platform debuggers.

An interesting data point for this discussion: msys2/MINGW-packages#5646

An interesting data point for this discussion: msys2/MINGW-packages#5646

This is also mentioned in #20039:

Zig uses PDB or CodeView format for debug symbols, while Rust and GCC use DWARF

When using Zig library in Rust or C on Windows, the mix of debug symbol formats makes either language un-debuggable

GDB has no support of PDB files (which use CodeView debug format) and LLDB's support is problematic ([1], [2]), which makes open-sourced VS Code debuggers like CodeLLDB unusable for zig debugging purposes

I'm not sure there's a default that's "good" here, and gnu being the default ABI for Windows in Zig makes the default matter.

Is the stuff in this PR related to 'targeting the MinGW ABI' or is it more related to 'emulating the MinGW toolchain'?

It's more about the latter. The goal of this PR is to improve compatibility.

lib/std/Build/Step/Compile.zig

…ile extension.

…ile formats

Added the `objFileExt()` function to Target, streamlining access to target-specific data in a manner consistent with other convenience functions.

…ader usage

…for enhanced flexibility

….dll` Aligns with other compilers' behavior.

alexrp reviewed Jan 5, 2025

View reviewed changes

lib/std/Target.zig Show resolved Hide resolved

alexrp reviewed Jan 5, 2025

View reviewed changes

src/main.zig Outdated Show resolved Hide resolved

Doekin force-pushed the mingw branch from 9e640f0 to 9bd0a5d Compare January 6, 2025 01:40

alexrp reviewed Jan 7, 2025

View reviewed changes

lib/std/Build/Step/Compile.zig Outdated Show resolved Hide resolved

Doekin force-pushed the mingw branch 3 times, most recently from 96a3649 to f32108e Compare January 7, 2025 07:39

alexrp reviewed Jan 7, 2025

View reviewed changes

lib/std/Build/Step/Compile.zig Outdated Show resolved Hide resolved

Doekin force-pushed the mingw branch from f32108e to e69c4ad Compare January 7, 2025 08:25

Doekin force-pushed the mingw branch 5 times, most recently from d5c44c9 to 8ae35c9 Compare February 4, 2025 02:16

alexrp mentioned this pull request Feb 5, 2025

look for libfoo.dll.a with mingw #22772

Open

Doekin force-pushed the mingw branch from 8ae35c9 to 64d867a Compare February 20, 2025 05:00

Doekin added 8 commits February 28, 2025 07:19

windows-gnu: Adhere to MinGW convention for debug format and object f…

956b59e

…ile extension.

windows-gnu: Add support for -mwindows option.

8de30ed

windows-gnu: Enhance MinGW library resolution to include additional f…

29ef145

…ile formats

Target: Add objFileExt() convenience wrapper

ec8fbaf

Added the `objFileExt()` function to Target, streamlining access to target-specific data in a manner consistent with other convenience functions.

Debug: Move Compilation.Config.DebugFormat to std.builtin for bro…

274a21b

…ader usage

Debug: Replace Module.dwarf_format with std.builtin.debug_format …

580aaf3

…for enhanced flexibility

windows-gnu: Add support for -gcodeview flag

6b13594

build: Disable default import library emission for .exe and MinGW `…

291114b

….dll` Aligns with other compilers' behavior.

Doekin force-pushed the mingw branch from 64d867a to b79eeb7 Compare February 27, 2025 23:24

link: Simplify library path resolution logic

3caf98a

Doekin force-pushed the mingw branch from b79eeb7 to 3caf98a Compare February 28, 2025 02:22

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

`windows-gnu`: Adhere to MinGW convention for build outputs #22415

`windows-gnu`: Adhere to MinGW convention for build outputs #22415

Doekin commented Jan 5, 2025 •

edited

Loading

alexrp commented Jan 5, 2025

Doekin commented Jan 5, 2025

alexrp commented Jan 5, 2025

alexrp Jan 7, 2025

squeek502 Jan 7, 2025 •

edited

Loading

kcbanner Jan 7, 2025

alexrp Jan 7, 2025

squeek502 Jan 7, 2025 •

edited

Loading

Doekin Jan 7, 2025

windows-gnu: Adhere to MinGW convention for build outputs #22415

Are you sure you want to change the base?

windows-gnu: Adhere to MinGW convention for build outputs #22415

Conversation

Doekin commented Jan 5, 2025 • edited Loading

Background

Changes

Example

Before

After

alexrp commented Jan 5, 2025

Doekin commented Jan 5, 2025

alexrp commented Jan 5, 2025

alexrp Jan 7, 2025

Choose a reason for hiding this comment

squeek502 Jan 7, 2025 • edited Loading

Choose a reason for hiding this comment

kcbanner Jan 7, 2025

Choose a reason for hiding this comment

alexrp Jan 7, 2025

Choose a reason for hiding this comment

squeek502 Jan 7, 2025 • edited Loading

Choose a reason for hiding this comment

Doekin Jan 7, 2025

Choose a reason for hiding this comment

`windows-gnu`: Adhere to MinGW convention for build outputs #22415

`windows-gnu`: Adhere to MinGW convention for build outputs #22415

Doekin commented Jan 5, 2025 •

edited

Loading

squeek502 Jan 7, 2025 •

edited

Loading

squeek502 Jan 7, 2025 •

edited

Loading