Support generating import libraries from mingw .def files without LLVM #25414
+2,231
−105
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Eliminates a dependency on LLVM with regards to the set of MinGW .def files shipped with Zig. This implementation is largely based on the LLVM implementation (specifically COFFModuleDefinition.cpp and COFFImportFile.cpp).
How this was tested
I developed/tested this in a separate repository here (the
def.zig
/implib.zig
files are 1:1 between that repository and this PR)I have a branch of zig here that adds a
zig implib
command that takes in a.def
file and outputs two files: a.pp.def
file that's the result of preprocessing with Aro (this is something that always happens duringbuildImportLib
), and a.lib
file that's the result of callingllvm_bindings.WriteImportLibrary
after preprocessing.I then have a
gen.zig
script here that walks Zig'slib/libc/mingw
directory and spawnszig implib
to create.pp.def
/.lib
pairs for every.def
and.def.in
file found.Finally, I have a
check.zig
script here that walks a directory of these generated pairs and confirms that the new implementation generates a byte-for-byte identical.lib
file for each.pp.def
input.The
check.zig
script passes cleanly for the entirelib/libc/mingw
directory when targeting all supportedwindows-gnu
targets: x86_64, x86, thumb, and aarch64 (see here for why these are specified).(note that the byte-for-byte nature means that the implementation has inherited a few quirks from LLVM around size counts/padding; those quirks have been kept for now just to ensure there's no possible breakage, but that should be revisited when eliminating the LLD dependency for COFF)
How this fits into the bigger picture
There are effectively two parts to this implementation:
.def
file parsing.lib
file writing (import library using the COFF archive file format)In theory, the second part could be made redundant once the self-hosted COFF linker is ready, since actually writing out the archive file format is not a necessary component of linking--all the required information exists in the
.def
file.However, the archive file writing implementation is not (in principle) COFF-specific (although the current implementation is), so in the future:
.def
file parsing as an input and skip the COFF import library generationIf #17807 is specifically about MinGW .def files, then this closes #17807