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