diff options
| author | Alex Rønne Petersen <alex@alexrp.com> | 2025-03-18 04:40:22 +0100 |
|---|---|---|
| committer | Alex Rønne Petersen <alex@alexrp.com> | 2025-03-18 10:58:52 +0100 |
| commit | 074dd4d083b8ddefc370425568b61c890efe905d (patch) | |
| tree | 098fb0b0bd29588fae3e1e12288593b0e795f816 /src/main.zig | |
| parent | 2a4e06bcb30f71e83b14026bcbade6aac3aece84 (diff) | |
| download | zig-074dd4d083b8ddefc370425568b61c890efe905d.tar.gz zig-074dd4d083b8ddefc370425568b61c890efe905d.zip | |
mingw: Rename mingw32.lib to libmingw32.lib.
LLD expects the library file name (minus extension) to be exactly libmingw32. By
calling it mingw32 previously, we prevented it from being detected as being in
LLD's list of libraries that are excluded from the MinGW-specific auto-export
mechanism.
https://github.com/llvm/llvm-project/blob/b9d27ac252265839354fffeacaa8f39377ed7424/lld/COFF/MinGW.cpp#L30-L56
As a result, a DLL built for *-windows-gnu with Zig would export a bunch of
internal MinGW symbols. This sometimes worked out fine, but it could break at
link or run time when linking an EXE with a DLL, where both are targeting
*-windows-gnu and thus linking separate copies of mingw32.lib. In #23204, this
manifested as the linker getting confused about _gnu_exception_handler() because
it was incorrectly exported by the DLL while also being defined in the
mingw32.lib that was being linked into the EXE.
Closes #23204.
Diffstat (limited to 'src/main.zig')
0 files changed, 0 insertions, 0 deletions