On Wednesday 12 February 2025 22:31:03 Martin Storsjö wrote: > On Wed, 29 Jan 2025, Pali Rohár wrote: > > > On Monday 30 December 2024 22:48:25 Pali Rohár wrote: > > > 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? > > > > Hello, I would like to remind this change. > > > > PATCH 1, 2 plus the fixup from my email "Sun, 15 Dec 2024 13:58:58 +0100" > > should be everything needed for this change. > > > > Do you want to do more testing, or are you fine with this change and > > this direction? > > I think that we were ok with it - there were a couple of voices in favour of > it and none against it, so I guess it's fine. > > But instead of having to assemble it from separate fixups, can you resend > the full current version of it? > > // Martin
Ok, I squashed fixup and updated also commit message to include test cases. _______________________________________________ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
