在 2025-5-26 02:58, Martin Storsjö 写道:
On Sun, 25 May 2025, Jacek Caban wrote:I think that kind of massive duplication just doesn't scale. For example, when adding a new target like ARM64EC, are you suggesting we duplicate all the .def files for a fifth time, rather than just adjusting a few as we did?
In a hybrid ARM64X import library, for example, I see `CreateDXGIFactory` be exported as both `CreateDXGIFactory` and `#CreateDXGIFactory`.
I have very little knowledge about this new arch, hence mostly I respect your decisions. If we are still generating DEFs from DLLs, I'd prefer we not add a series of DEF files.
[There are pure ARM64 DLLs such as basesrv.dll, so not all arm64 DEFs can be reused.]
Yeah, I agree. That was also the original reason for why we started merging them originally; we had lib32, lib64 and libarm32, and wanted to add libarm64. (Also, at the time I didn't have the real OS yet to even dump the DLLs, so it would have been a copy of libarm32 anyway.)A lot of the differences we have stem from the fact that lib32, lib64 and libarm32, before starting unification, had been dumped from quite different windows versions.
The idea about generating DEFs from DLLs is doubleplusungood and is exactly the reason why we have unwanted symbols, like `DllRegisterServer`, `DllCanUnloadNow`, `DllGetClassObject`, and some which I removed a few days ago in 9c1dcbf0c6a990cabbad0d915110c601f1d32184, and some more which Jacek removed in 99d13399bf5fa6e19c3c445b62fff751f3dbf997.
Having separate lib32 and lib-common is, in one sense, the simplest form, where each of them can be dumped without any extra postprocessing (as long as it isn't a tricky DLL with architecture specific differences), either from a DLL or recreated from an MSVC import lib. (But it has the risk of divergence between lib32 and lib-common.)Going all in on an i386 based source for lib-common, for the stdcall suffixes, requires always checking with an i386 based library before doing any updates to the files, for better or worse.
If we generate DEF files from Windows SDK LIBs then we need no such checking. And today, whoever wants to do that really doesn't have to install Windows: On GitHub actions there are now images (including Windows on ARM!) with preinstalled development resources. The process can be made automatic.
-- Best regards, LIU Hao
OpenPGP_signature.asc
Description: OpenPGP digital signature
_______________________________________________ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
