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
_______________________________________________
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
