Re: [Mingw-w64-public] Patch WS2 Inline Functions
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.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 Your analysis is certainly correct, but I think this particular fix affects more cases than really needed - __CRT_INLINE is used in lots of places, and I think many (or at least some) of them are such where an external definition actually exists, and the behaviour of only taking the address of the external definition, and inlining only when the compiler thinks it's worthwhile, is the desired one. We've got a couple other defines for inline functions, I think __mingw_ovr might be one that is for inline functions where there doesn't exist any non-inline definition elsewhere. So it might be safer (or at least less disruptive) to just change individual functions, where we've checked that there's no corresponding external definition, to use that instead of flat out changing the macro affecting all of them. // Martin ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[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)&IN6_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
[Mingw-w64-public] clock_nanosleep(CLOCK_MONOTONIC ...
I'm curious - why does the implementation of 'clock_nanosleep()' not work with CLOCK_MONOTONIC, while 'clock_gettime()' does? Is there anything preventing an implementation? ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Discussion: Need new function declarations in propvarutil.h from wine
在 7/12/21 2:44 PM, Biswapriyo Nath 写道: Would you like to upstream that change? I am not the author of that commit and don't know why it was added. qt6-multimedia compiles fine without that NTSTATUS re-definition. FWIW, that typedef thing is a declaration, rather than a definition. This means that duplicates of such typedefs are allowed as long as they don't disagree with each other. I think the `#if...#endif` check may be removed. -- Best regards, LIU Hao OpenPGP_signature Description: OpenPGP digital signature ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
