Re: [Mingw-w64-public] [PATCH] wtypes.h: replace #include <...> with #include "..." for rpc
Been 3 months since my last email, what's going on with this? On Tue, Oct 19, 2021 at 11:03 PM Jonathan Marler wrote: > Jacek were you able to forward this discussion to Wine? If so do you have > a link to that discussion? Thanks. > > On Sun, Sep 5, 2021 at 9:27 AM LIU Hao wrote: > >> 在 2021-09-05 23:00, Jacek Caban 写道: >> > >> > They come from widl, so if we want this change, then widl needs to be >> changed instead. It looks like >> > the reverse was done in the past: >> > >> > >> https://source.winehq.org/git/wine.git/commitdiff/0bde2bbe010c68a54f8928469e89637a2322ae44 >> > >> > I don't know what was the reasoning there, it seems fine to change it >> back. >> > >> > >> >> Thanks for the information. It seems that, in Windows SDK 10.0.22000.0 >> the only non-WinRT header >> that is generated from an IDL and contains `#include ` is >> 'microsoft.diagnostics.appanalysis.h'. All other non-WinRT headers use "" >> instead of <>. Please >> forward this discussion to Wine; in case of any upstream changes, we can >> backport them to mingw-w64. >> >> >> -- >> Best regards, >> LIU Hao >> >> ___ >> Mingw-w64-public mailing list >> Mingw-w64-public@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public >> > ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] wtypes.h: replace #include <...> with #include "..." for rpc
Jacek were you able to forward this discussion to Wine? If so do you have a link to that discussion? Thanks. On Sun, Sep 5, 2021 at 9:27 AM LIU Hao wrote: > 在 2021-09-05 23:00, Jacek Caban 写道: > > > > They come from widl, so if we want this change, then widl needs to be > changed instead. It looks like > > the reverse was done in the past: > > > > > https://source.winehq.org/git/wine.git/commitdiff/0bde2bbe010c68a54f8928469e89637a2322ae44 > > > > I don't know what was the reasoning there, it seems fine to change it > back. > > > > > > Thanks for the information. It seems that, in Windows SDK 10.0.22000.0 the > only non-WinRT header > that is generated from an IDL and contains `#include ` is > 'microsoft.diagnostics.appanalysis.h'. All other non-WinRT headers use "" > instead of <>. Please > forward this discussion to Wine; in case of any upstream changes, we can > backport them to mingw-w64. > > > -- > Best regards, > LIU Hao > > ___ > Mingw-w64-public mailing list > Mingw-w64-public@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public > ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] make dsparse library common
> Just wondering. Is libdsparse.a actually required in a project? I None that I know of, except for my win32metadata projection that ensures I can link to all the libraries on Windows with all the functions/libraries that are declared in the win32metadata. On Mon, Oct 11, 2021 at 11:33 PM Biswapriyo Nath wrote: > Just wondering. Is libdsparse.a actually required in a project? I > cherry pick some of the APIs mentioned in dsparse.def file and MS > Docs[1] suggests to use ntdspapi instead. > > [1]: https://docs.microsoft.com/en-us/windows/win32/api/dsparse/ > ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] [PATCH] make dsparse library common
I've included the patch in the body of this email, but I'm using a
webclient which can trample the whitespace so I've also included the patch
as an attachment.
>From db50bba6b5fa5492292da7c152d001f8d62b7246 Mon Sep 17 00:00:00 2001
From: Jonathan Marler
Date: Mon, 11 Oct 2021 11:07:09 -0600
Subject: [PATCH] Make dsparse library common
Currently the dsparse library is limited only to arm32. However, I don't
see any architecture limitation to arm in the docs, in the win32metadata
project, and on my x86_64 machine I have the dsparse dll and can see it's
exports via dumpbin in C:\windows\system32\dsparse.dll. I'm not sure why
it was only added to arm32 but it appears to be common to all platforms.
Signed-off-by: Jonathan Marler
---
mingw-w64-crt/{libarm32 => lib-common}/dsparse.def | 0
mingw-w64-crt/lib32/Makefile.am| 1 +
mingw-w64-crt/lib64/Makefile.am| 1 +
mingw-w64-crt/libarm64/Makefile.am | 1 +
4 files changed, 3 insertions(+)
rename mingw-w64-crt/{libarm32 => lib-common}/dsparse.def (100%)
diff --git a/mingw-w64-crt/libarm32/dsparse.def
b/mingw-w64-crt/lib-common/dsparse.def
similarity index 100%
rename from mingw-w64-crt/libarm32/dsparse.def
rename to mingw-w64-crt/lib-common/dsparse.def
diff --git a/mingw-w64-crt/lib32/Makefile.am
b/mingw-w64-crt/lib32/Makefile.am
index 67a87a71d..be3181364 100644
--- a/mingw-w64-crt/lib32/Makefile.am
+++ b/mingw-w64-crt/lib32/Makefile.am
@@ -117,6 +117,7 @@ lib32_DATA += %reldir%/libdpnlobby.a
lib32_DATA += %reldir%/libdpvoice.a
lib32_DATA += %reldir%/libdsetup.a
lib32_DATA += %reldir%/libdsound.a
+lib32_DATA += %reldir%/libdsparse.a
lib32_DATA += %reldir%/libdsrole.a
lib32_DATA += %reldir%/libdssec.a
lib32_DATA += %reldir%/libdwmapi.a
diff --git a/mingw-w64-crt/lib64/Makefile.am
b/mingw-w64-crt/lib64/Makefile.am
index c0608b8cf..d55a206ee 100644
--- a/mingw-w64-crt/lib64/Makefile.am
+++ b/mingw-w64-crt/lib64/Makefile.am
@@ -135,6 +135,7 @@ lib64_DATA += %reldir%/libdsauth.a
lib64_DATA += %reldir%/libdskquota.a
lib64_DATA += %reldir%/libdsound3d.a
lib64_DATA += %reldir%/libdsound.a
+lib64_DATA += %reldir%/libdsparse.a
lib64_DATA += %reldir%/libdsprop.a
lib64_DATA += %reldir%/libdsquery.a
lib64_DATA += %reldir%/libdssec.a
diff --git a/mingw-w64-crt/libarm64/Makefile.am
b/mingw-w64-crt/libarm64/Makefile.am
index c039feb35..7a8d86a0c 100644
--- a/mingw-w64-crt/libarm64/Makefile.am
+++ b/mingw-w64-crt/libarm64/Makefile.am
@@ -80,6 +80,7 @@ libarm64_DATA += %reldir%/libdrprov.a
libarm64_DATA += %reldir%/libdsauth.a
libarm64_DATA += %reldir%/libdskquota.a
libarm64_DATA += %reldir%/libdsound.a
+libarm64_DATA += %reldir%/libdsparse.a
libarm64_DATA += %reldir%/libdsprop.a
libarm64_DATA += %reldir%/libdsquery.a
libarm64_DATA += %reldir%/libdsrole.a
--
2.25.4
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] wtypes.h: replace #include <...> with #include "..." for rpc
I could but this project builds with MSVC and I noticed that the MSVC headers are using the same include style for these 2 particular files. Note that we only need to change these 2 lines, to fix this. What reason is there not to change these 2 lines to fix this issue? If you google it there appears to be many projects with a header file named "rpc.h". On Fri, Sep 3, 2021 at 10:49 PM Biswapriyo Nath wrote: > I disagree with this change. Your project contains files with similar > name in mingw-w64. You should change your project file instead of the > opposite. > > > ___ > Mingw-w64-public mailing list > Mingw-w64-public@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public > ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] wtypes.h: replace #include <...> with #include "..." for rpc
That's odd, I attached it in the first email sent Aug 25. Here's the patch inline with my email and attached again >From 2ba8f0e43213f09f85cf653a8f0a726d9873399d Mon Sep 17 00:00:00 2001 From: Jonathan Marler Date: Wed, 25 Aug 2021 10:35:19 -0600 Subject: [PATCH] wtypes.h: replace #include <...> with #include "..." for rpc headers This replaces the include style for rpc.h and rpcndr.h inside the wtypes.h header. I found this issue when trying to compile my WindowsNfs project found here: https://github.com/marler8997/WindowsNfs. This project contains a file named "Rpc.h". This broke the mingw header files because wtypes.h ends up including my file instead of the one in the toolchain. I also verified that if I had a file named rpcndr.h in my project then the same issue occured. By changing these 2 lines to use #include "...", projects can have files named rpc.h and rpcndr.h and include without breaking the headers. Signed-off-by: Jonathan Marler --- mingw-w64-headers/include/wtypes.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/mingw-w64-headers/include/wtypes.h b/mingw-w64-headers/include/wtypes.h index 773716df8..fd60edb01 100644 --- a/mingw-w64-headers/include/wtypes.h +++ b/mingw-w64-headers/include/wtypes.h @@ -4,8 +4,8 @@ #ifndef __REQUIRED_RPCNDR_H_VERSION__ #define __REQUIRED_RPCNDR_H_VERSION__ 475 #endif -#include -#include +#include "rpc.h" +#include "rpcndr.h" #endif #ifndef COM_NO_WINDOWS_H -- 2.25.4 On Fri, Sep 3, 2021 at 3:54 PM Jacek Caban wrote: > Hi Jonathan, > > On 9/3/21 11:48 PM, Jonathan Marler wrote: > > Been another 4 days, anyone able to bring this patch in or review? > > > Your patch never arrived to the mailing list, it looks like the > attachment is missing. > > > Jacek > > ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] wtypes.h: replace #include <...> with #include "..." for rpc
Been another 4 days, anyone able to bring this patch in or review? On Mon, Aug 30, 2021 at 3:36 PM Jonathan Marler wrote: > Ping. The issue that this fixes is easy to reproduce. Just try to > compile any project with the mingw headers and add a file named "rpc.h" to > one of your local include directories and you'll get a bunch of errors > related to missing definitions. The 2-line patch attached to my previous > message should fix it. > > On Wed, Aug 25, 2021 at 10:42 AM Jonathan Marler > wrote: > >> This replaces the include style for rpc.h and rpcndr.h inside the >> wtypes.h header. I found this issue when trying to compile my WindowsNfs >> project found here: https://github.com/marler8997/WindowsNfs. This >> project contains a file named "Rpc.h". This broke the mingw header files >> because wtypes.h ends up including my file instead of the one in the >> toolchain. I also verified that if I had a file named rpcndr.h in my >> project then the same issue occurred. By changing these 2 lines to use >> #include "...", projects can have files named rpc.h and rpcndr.h and >> include without breaking the headers. >> > ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] wtypes.h: replace #include <...> with #include "..." for rpc
Ping. The issue that this fixes is easy to reproduce. Just try to compile any project with the mingw headers and add a file named "rpc.h" to one of your local include directories and you'll get a bunch of errors related to missing definitions. The 2-line patch attached to my previous message should fix it. On Wed, Aug 25, 2021 at 10:42 AM Jonathan Marler wrote: > This replaces the include style for rpc.h and rpcndr.h inside the wtypes.h > header. I found this issue when trying to compile my WindowsNfs project > found here: https://github.com/marler8997/WindowsNfs. This project > contains a file named "Rpc.h". This broke the mingw header files because > wtypes.h ends up including my file instead of the one in the toolchain. I > also verified that if I had a file named rpcndr.h in my project then the > same issue occurred. By changing these 2 lines to use #include "...", > projects can have files named rpc.h and rpcndr.h and include > without breaking the headers. > ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] [PATCH] wtypes.h: replace #include <...> with #include "..." for rpc
This replaces the include style for rpc.h and rpcndr.h inside the wtypes.h header. I found this issue when trying to compile my WindowsNfs project found here: https://github.com/marler8997/WindowsNfs. This project contains a file named "Rpc.h". This broke the mingw header files because wtypes.h ends up including my file instead of the one in the toolchain. I also verified that if I had a file named rpcndr.h in my project then the same issue occurred. By changing these 2 lines to use #include "...", projects can have files named rpc.h and rpcndr.h and include without breaking the headers. ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Patch WS2 Inline Functions
Ah that's good to know so we can look out for that when we take the next release. We try our best and we appreciate the time and help. On Fri, Jul 23, 2021, 12:08 AM Martin Storsjö wrote: > On Thu, 22 Jul 2021, Jonathan Marler wrote: > > > The linker errors were found by a Zig user and I took up the challenge > > to fix it (original issue > > here: https://github.com/ziglang/zig/issues/9364) > > Zig's using clang under the hood and on top of it, it adds automatic > > dynamic compilation of various libc implementations/bindings. For > > windows it dynamically builds .lib files from the mingw .def files as I > > understand(see > https://github.com/ziglang/zig/blob/18b8738069268cc913bbae9580d2d1 > > 70618a2ae9/src/mingw.zig#L277). It looks like it also builds .a files > > but ws2_32 seems to have been left out for some reason. > > Oh, I see. Yes, that definitely explains the issue. > > Some libraries (lib*crt*, libmingwex) contain a quite volatile set of > object files, and we tweak exactly which object files go into which > library (on which arch, because there are differences) regularly - I'd > hope that Zig keeps up with these changes too. > > // Martin > ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Patch WS2 Inline Functions
The linker errors were found by a Zig user and I took up the challenge to fix it (original issue here: https://github.com/ziglang/zig/issues/9364) Zig's using clang under the hood and on top of it, it adds automatic dynamic compilation of various libc implementations/bindings. For windows it dynamically builds .lib files from the mingw .def files as I understand (see https://github.com/ziglang/zig/blob/18b8738069268cc913bbae9580d2d170618a2ae9/src/mingw.zig#L277). It looks like it also builds .a files but ws2_32 seems to have been left out for some reason. On Thu, Jul 22, 2021 at 3:48 PM Martin Storsjö wrote: > Hi, > > On Thu, 22 Jul 2021, Jonathan Marler wrote: > > > Yes I think the problem was with my environment. I had libws2_32.lib > > available but did not have libws2_32.a, so I was missing the symbols > coming > > from the source files in ming2-w64-crt. Thanks for the clarification. > > Hmm, ok, that's definitely your issue then. (Where do you get such a file > even - from the WinSDK? Because mingw-w64 itself doesn't produce any *.lib > files at all.) > > // Martin > ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Patch WS2 Inline Functions
Thanks Martin,
Yes I think the problem was with my environment. I had libws2_32.lib
available but did not have libws2_32.a, so I was missing the symbols coming
from the source files in ming2-w64-crt. Thanks for the clarification.
On Thu, Jul 22, 2021 at 3:33 AM Martin Storsjö wrote:
> On Wed, 21 Jul 2021, Jonathan Marler wrote:
>
> > Yeah definitely revert, those redefinition errors are bad news.
> > The problem though is that I still get these undefined symbol errors
> > even with -lws2_32 with Clang. Forgive me if I'm mistaken here, but in
> > order for these symbols to be available, don't they need to be in
> > ws2_32.def? Is that right? If so, I don't see them in there which is
> > why I think I'm getting the linker errors.
>
> Your original testcase you posted works exactly the same for me with both
> GCC and Clang:
>
> $ cat ws.c
> #include
> int main(int argc, char **argv) {
> return (int)_IS_ADDR_UNSPECIFIED;
> }
> $ x86_64-w64-mingw32-gcc ws.c -w
> /usr/bin/x86_64-w64-mingw32-ld:
> /tmp/ccvc4epM.o:ws.c:(.rdata$.refptr.IN6_IS_ADDR_UNSPECIFIED[.refptr.IN6_IS_ADDR_UNSPECIFIED]+0x0):
>
> undefined reference to `IN6_IS_ADDR_UNSPECIFIED'
> collect2: error: ld returned 1 exit status
> $ x86_64-w64-mingw32-gcc ws.c -w -lws2_32
> $
> $ x86_64-w64-mingw32-clang ws.c -w
> ld.lld: error: undefined symbol: IN6_IS_ADDR_UNSPECIFIED
> >>> referenced by /tmp/ws-2350d6.o:(main)
> clang-13: error: linker command failed with exit code 1 (use -v to see
> invocation)
> $ x86_64-w64-mingw32-clang ws.c -w -lws2_32
> $
>
> The symbol doesn't have to be in ws2_32.def, libws2_32.a consists of both
> import entries (based on the def file) and statically linked regular
> object files. Check the file with nm libws2_32.a to see what it contains.
>
> // Martin
>
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Patch WS2 Inline Functions
Yeah definitely revert, those redefinition errors are bad news.
The problem though is that I still get these undefined symbol errors even
with -lws2_32 with Clang. Forgive me if I'm mistaken here, but in order
for these symbols to be available, don't they need to be in ws2_32.def? Is
that right? If so, I don't see them in there which is why I think I'm
getting the linker errors.
On Wed, Jul 21, 2021 at 4:17 PM Martin Storsjö wrote:
> Hi,
>
> On Wed, 21 Jul 2021, LIU Hao wrote:
>
> > 在 7/20/21 11:44 AM, Jonathan Marler 写道:
> >> How's this?
> >>
> >
> > Thanks for the update. I believe it's 100% safe, but let's have it in
> master
> > for a while and see whether something breaks.
>
> Actually it turns out that this does break building mingw-w64-crt (at
> least with Clang), with errors like these:
>
> ../libsrc/ws2tcpip/in6_addr_equal.c:9:5: error: redefinition of
> 'IN6_ADDR_EQUAL'
> int IN6_ADDR_EQUAL(const struct in6_addr *a,const struct in6_addr *b)
> ^
>
> /home/martin/fate/llvm-mingw/prefix/i686-w64-mingw32/include/ws2ipdef.h:244:21:
> note: previous definition is here
> WS2TCPIP_INLINE int IN6_ADDR_EQUAL(const struct in6_addr *a, const struct
> in6_ad
> dr *b) {
> ^
> 1 error generated.
>
>
> So given that, I think we need to revert this for now and get back to the
> drawing board with this change.
>
>
> Is the case that some of the functions listed as inline don't exist as
> non-inline versions in the library? In that case, the fix would be to make
> those individual ones available as non-inline too.
>
>
> But the error case that was quoted before, IN6_IS_ADDR_UNSPECIFIED, is
> defined in mingw-w64-crt/libsrc/ws2tcpip/in6_is_addr_unspecified.c. So is
> the issue that that particular function doesn't actually end up included
> in the right library, even though it exists in source? Doesn't seem so - I
> do get the IN6_IS_ADDR_UNSPECIFIED symbol in libws2_32.a.
>
>
> So, is the actual root issue that you're trying to fix, that you could get
> away with using IN6_IS_ADDR_UNSPECIFIED without linking -lws2_32 with GCC?
> So the function is made available in headers, but with attributes saying
> the compiler is entirely free to use a non-inline version if the compiler
> feels like it? And some project out there has implicitly started relying
> on this being inlined, without linking with the relevant library? In that
> case, the proper fix would be to actually link with the library.
>
>
> // Martin
>
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Patch WS2 Inline Functions
How's this? On Sun, Jul 18, 2021 at 12:18 AM LIU Hao wrote: > 在 2021-07-13 17:44, Jonathan Marler 写道: > >> Do things work out if you use the existing __mingw_ovr attribute define? > > > > It appears to fix the issue yes. Here's a patch with that solution: > > > > > > Would you please send a new patch as an attachment? This one seemed to be > corrupted due to > hard-wrapping. Also remember to sign off your patch. > > > -- > Best regards, > LIU Hao > > ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Patch WS2 Inline Functions
Yes I double checked and it appears I'm able to take the address of these functions even when they are static. This means last patch I sent that uses __mingw_ovr should work fine. On Tue, Jul 13, 2021 at 11:52 PM Martin Storsjö wrote: > On Tue, 13 Jul 2021, Jonathan Marler wrote: > > > I think the ideal solution would allow programs to take the address of > these > > functions since MSVC allows it. > > Well even with static inline, their address can be taken just fine, it's > just not identical across all translation units. I don't see that as a big > issue here, so I'd be fine with going with that approach. > > // Martin > > ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Patch WS2 Inline Functions
I think the ideal solution would allow programs to take the address of these functions since MSVC allows it. For this we could either find a version of inline attributes that allows emission and doesn't cause duplicate symbol errors during link, or, keep the headers as they are and provide the the definitions in the library explicitly. On Tue, Jul 13, 2021, 6:55 AM LIU Hao wrote: > 在 7/13/21 6:33 PM, Martin Storsjö 写道: > >> > >> It appears to fix the issue yes. Here's a patch with that solution: > >> > >> > > `static inline` looks the safest solution, as long as the address of those > functions aren't taken. > > > -- > Best regards, > LIU Hao > > ___ > Mingw-w64-public mailing list > Mingw-w64-public@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public > ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Patch WS2 Inline Functions
> I highly suggest you not play with this inline stuff. It's something very
fragile that works by
accident; any tiny change could be catastrophic.
Yeah this whole inline thing is a complete mess. But the headers are
currently broken with Clang, using any of those WS2TCP_INLINE functions
with clang will result in linker errors to unresolved symbols. See the
original email/patch for more details, but it appears tha Clang is choosing
not to inline some of the calls which makes it incompatible with
__gnu_inline__ which disables the function emission altogether. jon_y
suggested on IRC that we add these functions to the library itself which
may not be a bad idea at this point. It would mean not having to touch
these seemingly brittle header files.
> Do things work out if you use the existing __mingw_ovr attribute define?
It appears to fix the issue yes. Here's a patch with that solution:
From 8f4c87ad8b19bf904ae0357a09e52477d49abea3 Mon Sep 17 00:00:00 2001
From: Jonathan Marler
Date: Tue, 13 Jul 2021 03:37:56 -0600
Subject: [PATCH] Use __mingw_ovr for WS2TCPIP_INLINE
---
mingw-w64-headers/include/ws2ipdef.h | 4 ++--
mingw-w64-headers/include/ws2tcpip.h | 36 ++--
2 files changed, 20 insertions(+), 20 deletions(-)
diff --git a/mingw-w64-headers/include/ws2ipdef.h
b/mingw-w64-headers/include/ws2ipdef.h
index d440bbcb8..6b10db388 100644
--- a/mingw-w64-headers/include/ws2ipdef.h
+++ b/mingw-w64-headers/include/ws2ipdef.h
@@ -238,9 +238,9 @@ typedef struct group_source_req {
SOCKADDR_STORAGE gsr_source;
} GROUP_SOURCE_REQ, *PGROUP_SOURCE_REQ;
-#define WS2TCPIP_INLINE __CRT_INLINE
+#define WS2TCPIP_INLINE __mingw_ovr
-int IN6_ADDR_EQUAL(const struct in6_addr *,const struct in6_addr *);
+static int IN6_ADDR_EQUAL(const struct in6_addr *,const struct in6_addr *);
WS2TCPIP_INLINE int IN6_ADDR_EQUAL(const struct in6_addr *a, const struct
in6_addr *b) {
return !memcmp(a, b, sizeof(struct in6_addr));
}
diff --git a/mingw-w64-headers/include/ws2tcpip.h
b/mingw-w64-headers/include/ws2tcpip.h
index 0a7890bb3..cf7d28ba6 100644
--- a/mingw-w64-headers/include/ws2tcpip.h
+++ b/mingw-w64-headers/include/ws2tcpip.h
@@ -46,24 +46,24 @@ extern "C" {
extern const struct in6_addr in6addr_any;
extern const struct in6_addr in6addr_loopback;
-int IN6_IS_ADDR_UNSPECIFIED(const struct in6_addr *);
-int IN6_IS_ADDR_LOOPBACK(const struct in6_addr *);
-int IN6_IS_ADDR_MULTICAST(const struct in6_addr *);
-int IN6_IS_ADDR_LINKLOCAL(const struct in6_addr *);
-int IN6_IS_ADDR_SITELOCAL(const struct in6_addr *);
-int IN6_IS_ADDR_V4MAPPED(const struct in6_addr *);
-int IN6_IS_ADDR_V4COMPAT(const struct in6_addr *);
-int IN6_IS_ADDR_MC_NODELOCAL(const struct in6_addr *);
-int IN6_IS_ADDR_MC_LINKLOCAL(const struct in6_addr *);
-int IN6_IS_ADDR_MC_SITELOCAL(const struct in6_addr *);
-int IN6_IS_ADDR_MC_ORGLOCAL(const struct in6_addr *);
-int IN6_IS_ADDR_MC_GLOBAL(const struct in6_addr *);
-int IN6ADDR_ISANY(const struct sockaddr_in6 *);
-int IN6ADDR_ISLOOPBACK(const struct sockaddr_in6 *);
-void IN6_SET_ADDR_UNSPECIFIED(struct in6_addr *);
-void IN6_SET_ADDR_LOOPBACK(struct in6_addr *);
-void IN6ADDR_SETANY(struct sockaddr_in6 *);
-void IN6ADDR_SETLOOPBACK(struct sockaddr_in6 *);
+static int IN6_IS_ADDR_UNSPECIFIED(const struct in6_addr *);
+static int IN6_IS_ADDR_LOOPBACK(const struct in6_addr *);
+static int IN6_IS_ADDR_MULTICAST(const struct in6_addr *);
+static int IN6_IS_ADDR_LINKLOCAL(const struct in6_addr *);
+static int IN6_IS_ADDR_SITELOCAL(const struct in6_addr *);
+static int IN6_IS_ADDR_V4MAPPED(const struct in6_addr *);
+static int IN6_IS_ADDR_V4COMPAT(const struct in6_addr *);
+static int IN6_IS_ADDR_MC_NODELOCAL(const struct in6_addr *);
+static int IN6_IS_ADDR_MC_LINKLOCAL(const struct in6_addr *);
+static int IN6_IS_ADDR_MC_SITELOCAL(const struct in6_addr *);
+static int IN6_IS_ADDR_MC_ORGLOCAL(const struct in6_addr *);
+static int IN6_IS_ADDR_MC_GLOBAL(const struct in6_addr *);
+static int IN6ADDR_ISANY(const struct sockaddr_in6 *);
+static int IN6ADDR_ISLOOPBACK(const struct sockaddr_in6 *);
+static void IN6_SET_ADDR_UNSPECIFIED(struct in6_addr *);
+static void IN6_SET_ADDR_LOOPBACK(struct in6_addr *);
+static void IN6ADDR_SETANY(struct sockaddr_in6 *);
+static void IN6ADDR_SETLOOPBACK(struct sockaddr_in6 *);
WS2TCPIP_INLINE int IN6_IS_ADDR_UNSPECIFIED(const struct in6_addr *a) {
return ((a->s6_words[0]==0) && (a->s6_words[1]==0) && (a->s6_words[2]==0)
&& (a->s6_words[3]==0) && (a->s6_words[4]==0) && (a->s6_words[5]==0) &&
(a->s6_words[6]==0) && (a->s6_words[7]==0)); }
WS2TCPIP_INLINE int IN6_IS_ADDR_LOOPBACK(const struct in6_addr *a) {
return ((a->s6_words[0]==0) && (a->s6_words[1]==0) && (a->s6_words[2]==0)
&& (a->s6_words[3]==0) && (a->s6_words[4]==0) && (a->s6_words[5]==0) &&
(a->s6_words[6]==
Re: [Mingw-w64-public] Patch WS2 Inline Functions
That is a good point. Thanks for your help/guidance with this. Here's a
new patch where I've copied __CRT_INLINE and created a new __MSVC_INLINE
which is meant to behave like the origin MSVC inline
From fb39d994898b00ae52106b72f6c835821ae2b455 Mon Sep 17 00:00:00 2001
From: Jonathan Marler
Date: Tue, 13 Jul 2021 00:01:03 -0600
Subject: [PATCH] Define __MSVC_INLINE for inline functions that can be
emitted
The following example works with MSVC but will fail using the mingw headers:
#include
int main(int argc, char **argv) {
return (int)_IS_ADDR_UNSPECIFIED;
}
The reason for this is because MinGW is defining this
`IN6_IS_ADDR_UNSPECIFIED` function with
`extern inline __attribute__((__gnu_inline__))`. A function defined with
these attributes will
NEVER be emitted. This means you cannot take the address of the function
and if the compiler does not inline a call to it, then you'll get a linker
error.
In the Windows SDK in ws2ipdef.h, this function uses the `__inline`
attribute
https://docs.microsoft.com/en-us/cpp/cpp/inline-functions-cpp?view=msvc-160
> This keyword tells the compiler that inline expansion is preferred.
However, the compiler
> can create a separate instance of the function (instantiate) and create
standard calling
> linkages instead of inserting the code inline. Two cases where this
behavior can happen are:
> * Recursive Functions
> * Functions that are referred to through a pointer elsewhere in the
translation unit.
Note that this function is not defined in any .lib or .dll file in the
Windows sdk and/or runtime,
so the only way to be able to take the address of it from the example above
is if the compiler
is able to emit the function, or if it's defined elsewhere.
The problem here appears to be the inclusion of
`__attribute__((__gnu_inline__))` which is what
tells the compiler NEVER to emit the function definition. Removing this
attribute allows the compiler
to emit the function which allows its address to be taken, and prevents
linker errors if the compiler
decides not to inline a call to it.
Note that this applies to multiple functions in the ws2 header files.
To fix this, I've created a new __MSVC_INLINE that behaves like the MSVC
version of inline and
redefined the WS2 functions with this inline attribute instead of
__CRT_INLINE.
Signed-off-by: Jonathan Marler
---
mingw-w64-headers/crt/_mingw.h.in| 13 +
mingw-w64-headers/include/ws2ipdef.h | 2 +-
2 files changed, 14 insertions(+), 1 deletion(-)
diff --git a/mingw-w64-headers/crt/_mingw.h.in b/mingw-w64-headers/crt/_
mingw.h.in
index b7fb99f42..2bbd2b611 100644
--- a/mingw-w64-headers/crt/_mingw.h.in
+++ b/mingw-w64-headers/crt/_mingw.h.in
@@ -93,6 +93,19 @@ limitations in handling dllimport attribute. */
# endif
#endif
+/*__MSVC_INLINE: like MSVC's inline, compiler may emit the function being
defined */
+#ifdef __cplusplus
+# define __MSVC_INLINE inline
+#elif defined(_MSC_VER)
+# define __MSVC_INLINE __inline
+#else
+# if ((__MINGW_GNUC_PREREQ(4, 3) || defined(__clang__)) &&
__STDC_VERSION__ >= 199901L)
+# define __MSVC_INLINE extern inline
+# else
+# define __MSVC_INLINE extern __inline__
+# endif
+#endif
+
#if !defined(__MINGW_INTRIN_INLINE) && defined(__GNUC__)
#define __MINGW_INTRIN_INLINE extern __inline__
__attribute__((__always_inline__,__gnu_inline__))
#endif
diff --git a/mingw-w64-headers/include/ws2ipdef.h
b/mingw-w64-headers/include/ws2ipdef.h
index d440bbcb8..e45163949 100644
--- a/mingw-w64-headers/include/ws2ipdef.h
+++ b/mingw-w64-headers/include/ws2ipdef.h
@@ -238,7 +238,7 @@ typedef struct group_source_req {
SOCKADDR_STORAGE gsr_source;
} GROUP_SOURCE_REQ, *PGROUP_SOURCE_REQ;
-#define WS2TCPIP_INLINE __CRT_INLINE
+#define WS2TCPIP_INLINE __MSVC_INLINE
int IN6_ADDR_EQUAL(const struct in6_addr *,const struct in6_addr *);
WS2TCPIP_INLINE int IN6_ADDR_EQUAL(const struct in6_addr *a, const struct
in6_addr *b) {
--
2.25.4
On Tue, Jul 13, 2021 at 12:50 AM Martin Storsjö wrote:
> Hi Jonathan,
>
> On Tue, 13 Jul 2021, Jonathan Marler wrote:
>
> > The problem here appears to be the inclusion of
> > `__attribute__((__gnu_inline__))` which is what
> > tells the compiler NEVER to emit the function definition. Removing this
> > attribute allows the compiler
> > to emit the function which allows its address to be taken, and prevents
> > linker errors if the compiler
> > decides not to inline a call to it.
> >
> > Note that this applies to multiple functions in the ws2 header files.
> >
> > Signed-off-by: Jonathan Marler
> > ---
> > mingw-w64-headers/crt/_mingw.h.in | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/mingw-w64-headers/crt/_mingw.h.in b/mingw-w64-headers/crt/_
> > mingw.h.in
> > index b7fb99f42..002079910 100644
> > --- a/mingw-w64-headers/crt/_
[Mingw-w64-public] Patch WS2 Inline Functions
>From 2a06367f7c63d5782ae51af162d68ed2e783e389 Mon Sep 17 00:00:00 2001
From: Jonathan Marler
Date: Tue, 13 Jul 2021 00:01:03 -0600
Subject: [PATCH] Remove __attribute__((__gnu_inline__)) to allow compiler to
emit functions
The following example works with MSVC but will fail using the mingw headers:
#include
int main(int argc, char **argv) {
return (int)_IS_ADDR_UNSPECIFIED;
}
The reason for this is because MinGW is defining this
`IN6_IS_ADDR_UNSPECIFIED` function with
`extern inline __attribute__((__gnu_inline__))`. A function defined with
these attributes will
NEVER be emitted. This means you cannot take the address of the function
and if the compiler does not inline a call to it, then you'll get a linker
error.
In the Windows SDK in ws2ipdef.h, this function uses the `__inline`
attribute
https://docs.microsoft.com/en-us/cpp/cpp/inline-functions-cpp?view=msvc-160
> This keyword tells the compiler that inline expansion is preferred.
However, the compiler
> can create a separate instance of the function (instantiate) and create
standard calling
> linkages instead of inserting the code inline. Two cases where this
behavior can happen are:
> * Recursive Functions
> * Functions that are referred to through a pointer elsewhere in the
translation unit.
Note that this function is not defined in any .lib or .dll file in the
Windows sdk and/or runtime,
so the only way to be able to take the address of it from the example above
is if the compiler
is able to emit the function, or if it's defined elsewhere.
The problem here appears to be the inclusion of
`__attribute__((__gnu_inline__))` which is what
tells the compiler NEVER to emit the function definition. Removing this
attribute allows the compiler
to emit the function which allows its address to be taken, and prevents
linker errors if the compiler
decides not to inline a call to it.
Note that this applies to multiple functions in the ws2 header files.
Signed-off-by: Jonathan Marler
---
mingw-w64-headers/crt/_mingw.h.in | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mingw-w64-headers/crt/_mingw.h.in b/mingw-w64-headers/crt/_
mingw.h.in
index b7fb99f42..002079910 100644
--- a/mingw-w64-headers/crt/_mingw.h.in
+++ b/mingw-w64-headers/crt/_mingw.h.in
@@ -87,7 +87,7 @@ limitations in handling dllimport attribute. */
# define __CRT_INLINE __inline
#else
# if ((__MINGW_GNUC_PREREQ(4, 3) || defined(__clang__)) &&
__STDC_VERSION__ >= 199901L)
-# define __CRT_INLINE extern inline __attribute__((__gnu_inline__))
+# define __CRT_INLINE extern inline
# else
# define __CRT_INLINE extern __inline__
# endif
--
2.25.4
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
