On Sat, 14 Dec 2024, Pali Rohár wrote:
Now all I386 symbols in lib-common/ws2_32.def.in file are defined with
stdcall @<num> suffixes. These suffixes are automatically removed for
non-I386 builds by Makefile.am rule during processing of
lib-common/*.def.in files.
During merging of lib32/ws2_32.def and lib-common/ws2_32.def.in files,
all symbols were sorted in the final file.
---
mingw-w64-crt/lib-common/ws2_32.def.in | 362 ++++++++++++-------------
mingw-w64-crt/lib32/ws2_32.def | 188 -------------
2 files changed, 181 insertions(+), 369 deletions(-)
delete mode 100644 mingw-w64-crt/lib32/ws2_32.def
A change like this looks acceptable to me. It's very hard to keep track of
what happens here though, but we would need to trust you to verify that
the output set of symbols stays the same (or ends up as a supserset of the
previous set of symbols) for each architecture - or set up procedures for
doublechecking it. (In some cases, adding symbols that didn't exist before
can be problematic, e.g. in case of some symbols in kernel32.dll or
similar, but for most cases, making the def files include more symbols
than before is fine.)
Here, it's a bit tricky/awkward when we already have some symbols within
F64(), like F64(WSCEnableNSProvider32) - as those don't get any stdcall
suffix, as there is no reference for what the suffix would be in that
case.
// Martin
_______________________________________________
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
