On Sunday 29 December 2024 17:46:22 Martin Storsjö wrote: > 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.)
I understand. I did my own checks that the list of symbols for individual arch after running those preprocessing, is same as before this change. No symbol added or removed. > 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 That is cost of the fact that "no new symbol for i386 was added" by this change. I have not even tried to check if that symbol is in some new version of ws2_32 for I386 or not. Do you think that this is a direction which can follow? Biswapriyo, what is your opinion? Would it be easier or harder to do new changes in def files? _______________________________________________ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
