Jonathan Yong

mingw-w64-headers/crt/corecrt.h: fix cygwin w32api usage

There's no longer any need to ship libhamlib-4.lib if is generated from dlltool (as opposed to MSVC lib.exe) since libhamlib.dll.a fulfills the same role for gcc. You can still include it for gcc for users who are still expect it to named libhamlib-4.lib. For MSVC, the .def file alone is sufficient for use by lib.exe to generate MSVC compatible libraries.

_mingw_mac.h: bump to 14.x

winpthreads: Regenerate Makefile.in

Please send it to the mailing list, merge requests aren't always monitored.

https://learn.microsoft.com/en-us/cpp/build/reference/lib-input-files?view=msvc-170 It should be LIB.EXE /DEF:libhamlib-4.def You can distribute the def file, MSVC users can run LIB.EXE themselves since it comes as part of MSVC.

You can use the "file" command on DLLs, it will print something like "PE32+ executable (DLL) (console) x86-64 (stripped to external PDB), for MS Windows, 11 sections". Again, you should use lib.exe from MSVC to produce MSVC compatible import libraries, dlltool produces binaries for mingw, not MSVC.

Using lib.exe on the def file is correct, but obviously you should match the architecture of the actual DLL associated with the def file. Static archives cannot be used with Visual Studio since the archive format isn't fully compatible. Edit: dlltool will not generate archives correctly for MSVC either, use lib.exe from MSVC to produce MSVC compatible import libraries.