On Sun, 25 May 2025, Jacek Caban wrote:

On 24.05.2025 12:25, LIU Hao wrote:
在 2025-5-24 18:12, Pali Rohár 写道:
And it deduplicated 496 def files. What do you think about it? Just a
robotic change and can decrease number of def files which needs to be
maintained.

I don't have a specific opinion on this change.

Frankly speaking, I am not too happy about the characteristic of 'lib-common': Some of x86-64, ARM32 and ARM64 libraries provide exact same sets of symbols, but some of them don't. The differences are random and arbitrary, which require maintenance with macros in 'func.def.in'; however keeping track of all the tiny pieces of inconsistency is largely unpractical. I'd prefer we generate DEFs from LIBs from Windows SDK and blindly accept the divergence.


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?

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.

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.

// Martin

_______________________________________________
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Reply via email to