Re: [Mingw-w64-public] Rust test failure after some math functions were moved
Le mercredi 17 avril 2024 à 23:13:18 UTC+2, Martin Storsjö a écrit : On Tue, 16 Apr 2024, philippe renon via Mingw-w64-public wrote: > All this to ask whether that "breaking" change was intentional ? The change itself was quite intentional, the breakage obviously wasn't intentional. We have a fair bit of these kinds of circular dependencies between libmingwex.a and libmsvcr*.a. And we'll probably get more of them, not less, as we specialize some of our helper routines into different versions for different CRTs (like this change). So therefore, breakage of this kind is indeed not surprising, when linking with ld.bfd, if the libs aren't specified repeatedly. When driving linking with GCC and Clang, the linker is already invoked with multiple "-lmsvcrt -lmingwex [..] -lmsvcrt -lmingwex". There are also other similar issues that we've had to fix by adding more of these duplicate linker options, see e.g. https://github.com/gcc-mirror/gcc/commit/850533ab160ef40eccfd039e1e3b138cf26e76b8. This is not an issue with lld, because it scans for symbols in all loaded libraries, not in the strict sequential manner that ld.bfd does. Alternatively, instead of just repeating these linker options over and over, we could consider to add --start-group --end-group around these linker options, in GCC, Clang and Rust, which would allow resolving any of the dependencies in these libraries among themselves. Clang already passes this, see e.g. https://github.com/llvm/llvm-project/blob/llvmorg-18.1.4/clang/lib/Driver/ToolChains/MinGW.cpp#L277-L348, but it only seems to do this when intending to link statically. Perhaps this should be done unconditionally - this is already done for some targets, see e.g. https://github.com/llvm/llvm-project/blob/llvmorg-18.1.4/clang/lib/Driver/ToolChains/NaCl.cpp#L146-L147. // Martin Thanks for in depth reply.I have reported the issue to Rust : https://github.com/rust-lang/rust/issues/124221 ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Rust test failure after some math functions were moved
The Rust test that failed uses the gamma function that depends on sin and log. So sin and log showed up in the link failure. I would expect cos to be problematic too.But I can't provide an exhaustive list. Le mardi 16 avril 2024 à 17:40:34 UTC+2, philippe renon via Mingw-w64-public a écrit : Note that there are more math functions involved (not just sin). See the commit that introduced the issue for a full list: https://github.com/mingw-w64/mingw-w64/commit/a64c1f4b969cff5f9e81c9a760117dc1b92d6ee1 Le mardi 16 avril 2024 à 16:44:31 UTC+2, Jacek Caban a écrit : On 16.04.2024 15:51, philippe renon via Mingw-w64-public wrote: > The error seems to happen because Rust pulls in lgamma from > libmingwex.a, which pulls in sin from libmsvcrt.a, which in turn tries > to pull in __sinl_internal from libmingwex.a and fails because of how > Rust links MinGW libs: > let mingw_libs = &[ > "-lmsvcrt", > "-lmingwex", > "-lmingw32", > "-lgcc", // alas, mingw* libraries above depend on libgcc > // mingw's msvcrt is a weird hybrid import library and static > library. > // And it seems that the linker fails to use import symbols from > msvcrt > // that are required from functions in msvcrt in certain cases. For > example > // `_fmode` that is used by an implementation of `__p__fmode` in > x86_64. > // The library is purposely listed twice to fix that. > // > // Seehttps://github.com/rust-lang/rust/pull/47483 for some more >details. > "-lmsvcrt", > "-luser32", > "-lkernel32", > ]; > https://github.com/rust-lang/rust/blob/aa6a697a1c75b0aa06954136f7641706edadc2be/compiler/rustc_target/src/spec/base/windows_gnu.rs#L30 > Due to how ld.bfd works it'd need another "-lmingwex", after second > "-lmsvcrt", since this change: mingw-w64/mingw-w64@a64c1f4 > If I'm right UCRT and LLD (with any CRT) are unaffected. > > The proposed fix worked. > All this to ask whether that "breaking" change was intentional ? Adding "-lmingwex" twice would generally make it more compatible with GCC, so there is an argument to do that. But in this particular case, I think we may improve things on mingw-w64-crt side and move __sinl_internal to msvcr* importlibs. Something like the attached (untested) patch should help. Thanks, Jacek ___ 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] Rust test failure after some math functions were moved
Note that there are more math functions involved (not just sin). See the commit that introduced the issue for a full list: https://github.com/mingw-w64/mingw-w64/commit/a64c1f4b969cff5f9e81c9a760117dc1b92d6ee1 Le mardi 16 avril 2024 à 16:44:31 UTC+2, Jacek Caban a écrit : On 16.04.2024 15:51, philippe renon via Mingw-w64-public wrote: > The error seems to happen because Rust pulls in lgamma from > libmingwex.a, which pulls in sin from libmsvcrt.a, which in turn tries > to pull in __sinl_internal from libmingwex.a and fails because of how > Rust links MinGW libs: > let mingw_libs = &[ > "-lmsvcrt", > "-lmingwex", > "-lmingw32", > "-lgcc", // alas, mingw* libraries above depend on libgcc > // mingw's msvcrt is a weird hybrid import library and static > library. > // And it seems that the linker fails to use import symbols from > msvcrt > // that are required from functions in msvcrt in certain cases. For > example > // `_fmode` that is used by an implementation of `__p__fmode` in > x86_64. > // The library is purposely listed twice to fix that. > // > // Seehttps://github.com/rust-lang/rust/pull/47483 for some more >details. > "-lmsvcrt", > "-luser32", > "-lkernel32", > ]; > https://github.com/rust-lang/rust/blob/aa6a697a1c75b0aa06954136f7641706edadc2be/compiler/rustc_target/src/spec/base/windows_gnu.rs#L30 > Due to how ld.bfd works it'd need another "-lmingwex", after second > "-lmsvcrt", since this change: mingw-w64/mingw-w64@a64c1f4 > If I'm right UCRT and LLD (with any CRT) are unaffected. > > The proposed fix worked. > All this to ask whether that "breaking" change was intentional ? Adding "-lmingwex" twice would generally make it more compatible with GCC, so there is an argument to do that. But in this particular case, I think we may improve things on mingw-w64-crt side and move __sinl_internal to msvcr* importlibs. Something like the attached (untested) patch should help. Thanks, 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] Rust test failure after some math functions were moved
Forgot to mention that this issue affects the MSYS2 build of Rust.See https://github.com/msys2/MINGW-packages/pull/20397#issuecomment-2050581972 Le mardi 16 avril 2024 à 14:29:22 UTC+2, philippe renon via Mingw-w64-public a écrit : One of the Rust unit test fails because of this change : https://github.com/mingw-w64/mingw-w64/commit/a64c1f4b969cff5f9e81c9a760117dc1b92d6ee1 The test that fails is externally linking the lgamma function : https://github.com/rust-lang/rust/blob/c2239bca5b89a8d3573cc0fc0f2fa65c50edb79c/tests/ui/issues/issue-2214.rs#L30 And fails with: [ui] tests\ui\issues\issue-2214.rs stdout error: test compilation failed although it shouldn't! status: exit code: 1 command: PATH="C:\M\mingw-w64-rust\src\MINGW64\build\x86_64-pc-windows-gnu\stage2\bin;C:\M\mingw-w64-rust\src\MINGW64\build\x86_64-pc-windows-gnu\stage0-bootstrap-tools\x86_64-pc-windows-gnu\release\deps;C:\M\mingw-w64-rust\src\MINGW64\build\x86_64-pc-windows-gnu\stage0\bin;C:\msys64\mingw64\bin;C:\msys64\usr\local\bin;C:\msys64\usr\bin;C:\msys64\usr\bin;C:\Windows\System32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\msys64\usr\bin\site_perl;C:\msys64\usr\bin\vendor_perl;C:\msys64\usr\bin\core_perl" "C:\\M\\mingw-w64-rust\\src\\MINGW64\\build\\x86_64-pc-windows-gnu\\stage2\\bin\\rustc.exe" "C:\\M\\mingw-w64-rust\\src\\rustc-1.77.1-src\\tests\\ui\\issues\\issue-2214.rs" "-Zthreads=1" "-Zsimulate-remapped-rust-src-base=/rustc/FAKE_PREFIX" "-Ztranslate-remapped-path-to-local-path=no" "-Z" "ignore-directory-in-diagnostics-source-blocks=C:\\Users\\Philippe\\.cargo" "--sysroot" "C:\\M\\mingw-w64-rust\\src\\MINGW64\\build\\x86_64-pc-windows-gnu\\stage2" "--target=x86_64-pc-windows-gnu" "-O" "--error-format" "json" "--json" "future-incompat" "-Ccodegen-units=1" "-Zui-testing" "-Zdeduplicate-diagnostics=no" "-Zwrite-long-types-to-disk=no" "-Cstrip=debuginfo" "-C" "prefer-dynamic" "-o" "C:\\M\\mingw-w64-rust\\src\\MINGW64\\build\\x86_64-pc-windows-gnu\\test\\ui\\issues\\issue-2214\\a.exe" "-A" "internal_features" "-Crpath" "-Cdebuginfo=0" "-Lnative=C:\\M\\mingw-w64-rust\\src\\MINGW64\\build\\x86_64-pc-windows-gnu\\native\\rust-test-helpers" "-L" "C:\\M\\mingw-w64-rust\\src\\MINGW64\\build\\x86_64-pc-windows-gnu\\test\\ui\\issues\\issue-2214\\auxiliary" stdout: none --- stderr --- error: linking with `x86_64-w64-mingw32-gcc` failed: exit code: 1 | = note: "x86_64-w64-mingw32-gcc" "-fno-use-linker-plugin" "-Wl,--dynamicbase" "-Wl,--disable-auto-image-base" "-m64" "-Wl,--high-entropy-va" "C:\\M\\mingw-w64-rust\\src\\MINGW64\\build\\x86_64-pc-windows-gnu\\stage2\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib\\rsbegin.o" "C:\\msys64\\tmp\\rustcI8gS1G\\symbols.o" "C:\\M\\mingw-w64-rust\\src\\MINGW64\\build\\x86_64-pc-windows-gnu\\test\\ui\\issues\\issue-2214\\a.issue_2214.acb96087d874e44a-cgu.0.rcgu.o" "-L" "C:\\M\\mingw-w64-rust\\src\\MINGW64\\build\\x86_64-pc-windows-gnu\\native\\rust-test-helpers" "-L" "C:\\M\\mingw-w64-rust\\src\\MINGW64\\build\\x86_64-pc-windows-gnu\\test\\ui\\issues\\issue-2214\\auxiliary" "-L" "C:\\M\\mingw-w64-rust\\src\\MINGW64\\build\\x86_64-pc-windows-gnu\\stage2\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib" "-L" "C:\\M\\mingw-w64-rust\\src\\MINGW64\\build\\x86_64-pc-windows-gnu\\stage2\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib" "-Wl,-Bdynamic" "-lstd-52a03da70d492f12" "-Wl,-Bstatic" "C:\\M\\mingw-w64-rust\\src\\MINGW64\\build\\x86_64-pc-windows-gnu\\stage2\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib\\libcompiler_builtins-91ce6b54f8d65f85.rlib" "-Wl,-Bdynamic" "-lkernel32" "-ladvapi32" "-lbcrypt" "-lkernel32" "-lntdll" "-luserenv" "-lws2_32" "-lkernel32" "-lws2_32" "-lkernel32" "-lntdll" "-lkernel32" "-lgcc_s" "-lmsvcrt" "-lmingwex" "-lmingw32" "-lgcc" "-lmsvcrt" "-luser32" "-lkernel32" "-Wl,--nxcompat" "-L" "C:\\M\\mingw-w64-rust\\src\\MINGW64\\build\\x86_64-pc-windows-gnu\\stage2\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib" "-o" "C:\\M\\mingw-w64-rust\\src\\MINGW64\\build\\x86_64-pc-windows-gnu\\test\\ui\\issues\\issue-2214\\a.exe" "-Wl,--gc-sections" "-no-pie" "-Wl,-O1" "-Wl,--stri
[Mingw-w64-public] Rust test failure after some math functions were moved
One of the Rust unit test fails because of this change : https://github.com/mingw-w64/mingw-w64/commit/a64c1f4b969cff5f9e81c9a760117dc1b92d6ee1 The test that fails is externally linking the lgamma function : https://github.com/rust-lang/rust/blob/c2239bca5b89a8d3573cc0fc0f2fa65c50edb79c/tests/ui/issues/issue-2214.rs#L30 And fails with: [ui] tests\ui\issues\issue-2214.rs stdout error: test compilation failed although it shouldn't! status: exit code: 1 command: PATH="C:\M\mingw-w64-rust\src\MINGW64\build\x86_64-pc-windows-gnu\stage2\bin;C:\M\mingw-w64-rust\src\MINGW64\build\x86_64-pc-windows-gnu\stage0-bootstrap-tools\x86_64-pc-windows-gnu\release\deps;C:\M\mingw-w64-rust\src\MINGW64\build\x86_64-pc-windows-gnu\stage0\bin;C:\msys64\mingw64\bin;C:\msys64\usr\local\bin;C:\msys64\usr\bin;C:\msys64\usr\bin;C:\Windows\System32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\msys64\usr\bin\site_perl;C:\msys64\usr\bin\vendor_perl;C:\msys64\usr\bin\core_perl" "C:\\M\\mingw-w64-rust\\src\\MINGW64\\build\\x86_64-pc-windows-gnu\\stage2\\bin\\rustc.exe" "C:\\M\\mingw-w64-rust\\src\\rustc-1.77.1-src\\tests\\ui\\issues\\issue-2214.rs" "-Zthreads=1" "-Zsimulate-remapped-rust-src-base=/rustc/FAKE_PREFIX" "-Ztranslate-remapped-path-to-local-path=no" "-Z" "ignore-directory-in-diagnostics-source-blocks=C:\\Users\\Philippe\\.cargo" "--sysroot" "C:\\M\\mingw-w64-rust\\src\\MINGW64\\build\\x86_64-pc-windows-gnu\\stage2" "--target=x86_64-pc-windows-gnu" "-O" "--error-format" "json" "--json" "future-incompat" "-Ccodegen-units=1" "-Zui-testing" "-Zdeduplicate-diagnostics=no" "-Zwrite-long-types-to-disk=no" "-Cstrip=debuginfo" "-C" "prefer-dynamic" "-o" "C:\\M\\mingw-w64-rust\\src\\MINGW64\\build\\x86_64-pc-windows-gnu\\test\\ui\\issues\\issue-2214\\a.exe" "-A" "internal_features" "-Crpath" "-Cdebuginfo=0" "-Lnative=C:\\M\\mingw-w64-rust\\src\\MINGW64\\build\\x86_64-pc-windows-gnu\\native\\rust-test-helpers" "-L" "C:\\M\\mingw-w64-rust\\src\\MINGW64\\build\\x86_64-pc-windows-gnu\\test\\ui\\issues\\issue-2214\\auxiliary" stdout: none --- stderr --- error: linking with `x86_64-w64-mingw32-gcc` failed: exit code: 1 | = note: "x86_64-w64-mingw32-gcc" "-fno-use-linker-plugin" "-Wl,--dynamicbase" "-Wl,--disable-auto-image-base" "-m64" "-Wl,--high-entropy-va" "C:\\M\\mingw-w64-rust\\src\\MINGW64\\build\\x86_64-pc-windows-gnu\\stage2\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib\\rsbegin.o" "C:\\msys64\\tmp\\rustcI8gS1G\\symbols.o" "C:\\M\\mingw-w64-rust\\src\\MINGW64\\build\\x86_64-pc-windows-gnu\\test\\ui\\issues\\issue-2214\\a.issue_2214.acb96087d874e44a-cgu.0.rcgu.o" "-L" "C:\\M\\mingw-w64-rust\\src\\MINGW64\\build\\x86_64-pc-windows-gnu\\native\\rust-test-helpers" "-L" "C:\\M\\mingw-w64-rust\\src\\MINGW64\\build\\x86_64-pc-windows-gnu\\test\\ui\\issues\\issue-2214\\auxiliary" "-L" "C:\\M\\mingw-w64-rust\\src\\MINGW64\\build\\x86_64-pc-windows-gnu\\stage2\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib" "-L" "C:\\M\\mingw-w64-rust\\src\\MINGW64\\build\\x86_64-pc-windows-gnu\\stage2\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib" "-Wl,-Bdynamic" "-lstd-52a03da70d492f12" "-Wl,-Bstatic" "C:\\M\\mingw-w64-rust\\src\\MINGW64\\build\\x86_64-pc-windows-gnu\\stage2\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib\\libcompiler_builtins-91ce6b54f8d65f85.rlib" "-Wl,-Bdynamic" "-lkernel32" "-ladvapi32" "-lbcrypt" "-lkernel32" "-lntdll" "-luserenv" "-lws2_32" "-lkernel32" "-lws2_32" "-lkernel32" "-lntdll" "-lkernel32" "-lgcc_s" "-lmsvcrt" "-lmingwex" "-lmingw32" "-lgcc" "-lmsvcrt" "-luser32" "-lkernel32" "-Wl,--nxcompat" "-L" "C:\\M\\mingw-w64-rust\\src\\MINGW64\\build\\x86_64-pc-windows-gnu\\stage2\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib" "-o" "C:\\M\\mingw-w64-rust\\src\\MINGW64\\build\\x86_64-pc-windows-gnu\\test\\ui\\issues\\issue-2214\\a.exe" "-Wl,--gc-sections" "-no-pie" "-Wl,-O1" "-Wl,--strip-debug" "-nodefaultlibs" "C:\\M\\mingw-w64-rust\\src\\MINGW64\\build\\x86_64-pc-windows-gnu\\stage2\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib\\rsend.o" = note: C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw
Re: [Mingw-w64-public] __pformat_fpreg_bits: change to match __gdtoa prototype
On 1/18/24 16:45, LIU Hao wrote: 在 2024-01-19 00:01, JonY via Mingw-w64-public 写道: On 1/18/24 12:46, JonY wrote: Attached patch OK? Changes unsigned int to unsigned long to match __gdtoa due to gcc becoming more strict with pointer types. Attached v2 patch, removed #ifdef and made the type Ulong like the prototype. The v2 patch looks good to me. Thanks, pushed to master. ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] __pformat_fpreg_bits: change to match __gdtoa prototype
On 1/18/24 12:46, JonY wrote:
Attached patch OK?
Changes unsigned int to unsigned long to match __gdtoa due to gcc
becoming more strict with pointer types.
Attached v2 patch, removed #ifdef and made the type Ulong like the
prototype.
From 1415ff7f9b835e9ea39864c9625ec6fb72682918 Mon Sep 17 00:00:00 2001
From: Jonathan Yong <10wa...@gmail.com>
Date: Thu, 18 Jan 2024 12:42:51 +
Subject: [PATCH] __pformat_fpreg_bits: change to match __gdtoa prototype
The variable is only used within mingw_pformat.c, increasing
strictness in newer versions of GCC has turned this into an
error despite both integer widths are 32bit.
Correct so it matches the __gdtoa prototype declaration.
Signed-off-by: Jonathan Yong <10wa...@gmail.com>
---
mingw-w64-crt/stdio/mingw_pformat.c | 65 ++---
1 file changed, 3 insertions(+), 62 deletions(-)
diff --git a/mingw-w64-crt/stdio/mingw_pformat.c b/mingw-w64-crt/stdio/mingw_pformat.c
index 87902aea2..fd53ce1a8 100644
--- a/mingw-w64-crt/stdio/mingw_pformat.c
+++ b/mingw-w64-crt/stdio/mingw_pformat.c
@@ -1026,6 +1026,8 @@ void __pformat_xint( int fmt, __pformat_intarg_t value, __pformat_t *stream )
__pformat_putc( '\x20', stream );
}
+#include "../gdtoa/gdtoa.h"
+
typedef union
{
/* A multifaceted representation of an IEEE extended precision,
@@ -1039,15 +1041,9 @@ typedef union
signed short __pformat_fpreg_exponent;
};
unsigned short __pformat_fpreg_bitmap[5];
- unsigned int __pformat_fpreg_bits;
+ ULong __pformat_fpreg_bits;
} __pformat_fpreg_t;
-#ifdef _WIN32
-/* TODO: make this unconditional in final release...
- * (see note at head of associated `#else' block.
- */
-#include "../gdtoa/gdtoa.h"
-
static __pformat_fpreg_t init_fpreg_ldouble( long double val )
{
__pformat_fpreg_t x;
@@ -1167,61 +1163,6 @@ char *__pformat_fcvt( long double x, int precision, int *dp, int *sign )
#define __pformat_ecvt_release( value ) __freedtoa( value )
#define __pformat_fcvt_release( value ) __freedtoa( value )
-#else
-/*
- * TODO: remove this before final release; it is included here as a
- * convenience for testing, without requiring a working `__gdtoa()'.
- */
-static
-char *__pformat_ecvt( long double x, int precision, int *dp, int *sign )
-{
- /* Define in terms of `ecvt()'...
- */
- char *retval = ecvt( (double)(x), precision, dp, sign );
- if( isinf( x ) || isnan( x ) )
- {
-/* emulating `__gdtoa()' reporting for infinities and NaN.
- */
-*dp = PFORMAT_INFNAN;
-if( *retval == '-' )
-{
- /* Need to force the `sign' flag, (particularly for NaN).
- */
- ++retval; *sign = 1;
-}
- }
- return retval;
-}
-
-static
-char *__pformat_fcvt( long double x, int precision, int *dp, int *sign )
-{
- /* Define in terms of `fcvt()'...
- */
- char *retval = fcvt( (double)(x), precision, dp, sign );
- if( isinf( x ) || isnan( x ) )
- {
-/* emulating `__gdtoa()' reporting for infinities and NaN.
- */
-*dp = PFORMAT_INFNAN;
-if( *retval == '-' )
-{
- /* Need to force the `sign' flag, (particularly for NaN).
- */
- ++retval; *sign = 1;
-}
- }
- return retval;
-}
-
-/* No memory pool clean up needed, for these emulated cases...
- */
-#define __pformat_ecvt_release( value ) /* nothing to be done */
-#define __pformat_fcvt_release( value ) /* nothing to be done */
-
-/* TODO: end of conditional to be removed. */
-#endif
-
static
void __pformat_emit_radix_point( __pformat_t *stream )
{
--
2.43.0
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] __pformat_fpreg_bits: change to match __gdtoa prototype
Attached patch OK? Changes unsigned int to unsigned long to match __gdtoa due to gcc becoming more strict with pointer types.From b73262a164978a1733777e6628c00c3672794dea Mon Sep 17 00:00:00 2001 From: Jonathan Yong <10wa...@gmail.com> Date: Thu, 18 Jan 2024 12:42:51 + Subject: [PATCH] __pformat_fpreg_bits: change to match __gdtoa prototype The variable is only used within mingw_pformat.c, increasing strictness in newer versions of GCC has turned this into an error despite both integer widths are 32bit. Correct so it matches the __gdtoa prototype declaration. Signed-off-by: Jonathan Yong <10wa...@gmail.com> --- mingw-w64-crt/stdio/mingw_pformat.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/mingw-w64-crt/stdio/mingw_pformat.c b/mingw-w64-crt/stdio/mingw_pformat.c index 87902aea2..021c1eb4d 100644 --- a/mingw-w64-crt/stdio/mingw_pformat.c +++ b/mingw-w64-crt/stdio/mingw_pformat.c @@ -1039,7 +1039,7 @@ typedef union signed short __pformat_fpreg_exponent; }; unsigned short __pformat_fpreg_bitmap[5]; - unsigned int __pformat_fpreg_bits; + unsigned long __pformat_fpreg_bits; } __pformat_fpreg_t; #ifdef _WIN32 -- 2.43.0 ___ 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] crt: Add DnsCleanupTcpConnections to dnsapi
Mark Harmstone wrote: diff --git a/mingw-w64-crt/lib-common/dnsapi.def b/mingw-w64-crt/lib-common/dnsapi.def index 929deecd6..fae00a0a5 100644 --- a/mingw-w64-crt/lib-common/dnsapi.def +++ b/mingw-w64-crt/lib-common/dnsapi.def @@ -28,6 +28,7 @@ DnsAsyncRegisterTerm DnsCancelQuery DnsCheckNrptRuleIntegrity DnsCheckNrptRules +DnsCleanupTcpConnections DnsConnectionDeletePolicyEntries DnsConnectionDeletePolicyEntriesPrivate DnsConnectionDeleteProxyInfo Which API-version are these part of? E.g. 'DnsCleanupTcpConnections()' is not in my WinSDK ver 10.0.22621.0 'WinDNS.h'. And a search for: https://learn.microsoft.com/en-us/search/?terms=DnsCheckNrptRules gave nothing. So some of these are for internal use only? -- --gv ___ 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 14/18] winpthreads: AC_PROG_RANLIB is obsoleted by LT_INIT
On 11/29/23 10:39, Antonin Décimo wrote: Fixes a warning from libtoolize: 'AC_PROG_RANLIB' is rendered obsolete by 'LT_INIT'. Signed-off-by: Antonin Décimo --- mingw-w64-libraries/winpthreads/configure| 104 +-- mingw-w64-libraries/winpthreads/configure.ac | 1 - 2 files changed, 1 insertion(+), 104 deletions(-) Please exclude the configure file itself from the commit, regenerate it as a separate commit. Thanks. ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Define __STDC_NO_THREADS__ if C11/C17 is not provided
Mind that Clang also does *not* currently define `__STDC_NO_THREADS__` for MinGW target. For MSVC target, this define was added in <https://reviews.llvm.org/D112081>. Some of that discussion may also apply here. With glibc, apparently the compiler automatically includes `stdc-predef.h` which allows the libc to set this define, however there is no equivalent feature when it comes to MSVC and mingw-w64. It seems the only way to set this define for mingw-w64 is to hardcode it into the compiler. On 9/11/2023 15:42, LIU Hao wrote: 在 2023/11/9 15:14, Antonin Décimo 写道: I should be able to test this macro to choose to include `threads.h` or not, even if it is not predefined, it cannot be located in 'threads.h'. Someone may wish to use the same compiler consistently with older and newer C runtime libraries. It is likely cumbersome if the compiler would have had to look for a header before it could define a builtin macro. Is there no mechanism to allow this? gcc+glibc used to support it. Clang currently has the correct behaviour on most systems. Suppose: If clang currently defines `__STDC_NO_THREADS__`, does it stop doing so if we upgrade mingw-w64 so we start to have ? I see some problems here, although it is allowed to define __STDC_VERSION__ in C++ mode, most compilers don't define this macro in C++. `thread_local` is already a C++11 keyword. Yes that's why the macro `thread_local` shouldn't be defined for C++. In C23 the macro `thread_local` is removed, and `thread_local` becomes a keyword too. The `_Thread_local` type specifier is removed. It's a reserved word so a compiler is allowed to still provide it as an extension [1]. And I wonder whether there is a good reason that it will be removed. Keeping it as an extension has little cost, while removing it would break valid C11 code. Besides, providing an incomplete `threads.h` without all the C11 thread functions wouldn't be compliant, and quite counter-intuitive. I'd say it's not good. However, defining `__STDC_NO_THREADS__` in the compiler might not be even better; how can this compiler be used with a newer runtime library that actually provides ? To fix my issue, I might define __STDC_NO_THREADS__ at configure-time if the 'threads.h' header cannot be found. Maybe you can use `__has_include()` to check existence of the header [2]. [1] https://gcc.godbolt.org/z/dxoTj3Eqr [2] https://gcc.gnu.org/onlinedocs/gcc-9.5.0/cpp/_005f_005fhas_005finclude.html ___ 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] crt: Mark __guard_dispatch_icall_dummy as global
Seems reasonable to me, thanks for checking.
On 31/10/2023 18:14, Martin Storsjö wrote:
In LLVM LTO builds with cfguard enabled, the non-extern
__guard_dispatch_icall_dummy can't pose as replacement for the
undefined symbol reference to an extern __guard_dispatch_icall_dummy.
Signed-off-by: Martin Storsjö
---
mingw-w64-crt/cfguard/mingw_cfguard_support.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/mingw-w64-crt/cfguard/mingw_cfguard_support.c
b/mingw-w64-crt/cfguard/mingw_cfguard_support.c
index cf4535afd..1e777ebfc 100644
--- a/mingw-w64-crt/cfguard/mingw_cfguard_support.c
+++ b/mingw-w64-crt/cfguard/mingw_cfguard_support.c
@@ -20,6 +20,7 @@ static void __guard_check_icall_dummy(void) {}
// When CFGuard is not active, directly tail-call the target address, which
// is passed via %rax.
__asm__(
+".globl __guard_dispatch_icall_dummy\n"
"__guard_dispatch_icall_dummy:\n"
"jmp *%rax\n"
);
___
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] winpthreads: change LoadLibrary calls to GetModuleHandle after cb7f42e.
On 30.10.2023 22:09, Martin Storsjö wrote: On Mon, 30 Oct 2023, Jacek Caban wrote: GetTickCount64 is used only for _pthread_wait_for_*_objects wrappers, where the timeout is 32-bit anyway, so it should be possible to use GetTickCount unconditionally and avoid the whole problem. It would need a bit of overflow handling, but nothing too bad. However, looking at _pthread_wait_for_*_objects helpers, I'd argue that they don't make sense in the first. The comment claims that system functions have poor accuracy and then uses a function with the same accuracy to check that and unnecessary delay wait... I'd say we could just revert 52f2ce12c6182bd239e4f1bbffcd420997b64b08. Thanks for having a look at this level. However, I can kinda see the argument against returning too early though, so I could see that it makes sense to wrap WaitFor*Object(s) in a loop - do you agree with that? I find the claim that it's fine to wait for longer to be questionable. GetTickCount's value may be off by up to 16 ms, so the way elapsed time is calculated in those helpers may be off by up to 32 ms. I guess that precise waits matter mostly for short timeouts in scenarios where timeouts are semi-expected to happen and then the overhead of over-waiting may be not negligible. I wonder if the observed too short waits are an effect of measurements problems in tests, but I can't judge on that without seeing tests. All operating systems will have some sort of accuracy considerations in this area and kernel is in a better position to handle it than we are. Anyway, I realize that a revert to be controversial and don't intend to insist. Playing with plain GetTickCount is probably worth a try, through. 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] winpthreads: change LoadLibrary calls to GetModuleHandle after cb7f42e.
On 30.10.2023 16:39, Martin Storsjö wrote: On Mon, 30 Oct 2023, LIU Hao wrote: 在 2023-10-30 18:54, Martin Storsjö 写道: FWIW, this is what we already had before cb7f42e05b94cbb1d94edcebdbfb47b652a45484; we used GetTickCount64 unconditionally if _WIN32_WINNT was set to target vista or above. Since f3c53a51df5c08f181e13a39b1cd6fd1d41edb96, our default _WIN32_WINNT is set to target Win10, so a default-built toolchain will have a winpthread that doesn't run on versions below Vista - one of the intents in cb7f42e05b94cbb1d94edcebdbfb47b652a45484 was to make it so that one doesn't need to use a special built toolchain in order to run things on older versions of Windows. There was a reply from Christian Franke which mentioned support for XP, which still requires `GetModuleHandle()` or `LoadLibrary()` somehow. We may decide that Windows 98 is outdated and not primarily (if not completely) supported, but it does not seem to be the case with Windows XP, does it? Agreed. The history of this is that in 52f2ce12c6182bd239e4f1bbffcd420997b64b08, in 2019, we added conditional use of GetTickCount64 if building with _WIN32_WINNT >= _WIN32_WINNT_VISTA, but at the time, _WIN32_WINNT defaulted to XP. When f3c53a51df5c08f181e13a39b1cd6fd1d41edb96 bumped _WIN32_WINNT to default to Win10, default builds of winpthreads essentially stopped working on XP, unless one overrides the default _WIN32_WINNT. GetTickCount64 is used only for _pthread_wait_for_*_objects wrappers, where the timeout is 32-bit anyway, so it should be possible to use GetTickCount unconditionally and avoid the whole problem. It would need a bit of overflow handling, but nothing too bad. However, looking at _pthread_wait_for_*_objects helpers, I'd argue that they don't make sense in the first. The comment claims that system functions have poor accuracy and then uses a function with the same accuracy to check that and unnecessary delay wait... I'd say we could just revert 52f2ce12c6182bd239e4f1bbffcd420997b64b08. 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] winpthreads: change LoadLibrary calls to GetModuleHandle after cb7f42e.
On Tue, 24 Oct 2023, Ozkan Sezer wrote: > LoadLibrary needs cleaning after, and we do link to kernel32.dll anyway. How does this play out with winstore apps using winstorecompat? It seems that GetModuleHandle in winstorecompat always returns NULL, while LoadLibrary ends up calling LoadPackagedLibrary. I have never actually written such apps, so I don't know what LoadPackagedLibrary would return for kernel32.dll. I was actually originally thinking an implementation of GetProcAddress was provided to always return NULL, and that adding "support" for win 98 might have had an unintended consequence of forcing store apps to always use the fallback case. Perhaps that is the case now with GetModuleHandle. _______ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] regression in mingw-w64-crt/configure?
On Sun, 29 Oct 2023, Martin Storsjö wrote: > This was an accidentally pushed commit - I had generated files with a version > of autotools that I had on my system, different from the one we'ce normally > used. I reverted this accidentally pushed commit in > d6c07d9561a7af6c56ab2b0f6ee8c19e31ad9fd8. > > Sorry for the noise. Ah, and the update of mingw-w64 in msys2 updated to the commit *before* that revert, so I missed it. ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] regression in mingw-w64-crt/configure?
I was looking at the recent commits, and saw the following hunk in
f86c3e7bbd88d755bc8ab0f467b486bf475656a1
diff --git a/mingw-w64-crt/configure b/mingw-w64-crt/configure
index 68b4c63b2..4f1971a87 100755
--- a/mingw-w64-crt/configure
+++ b/mingw-w64-crt/configure
@@ -2062,7 +2062,9 @@ struct stat;
/* Most of the following tests are stolen from RCS 5.7 src/conf.sh. */
struct buf { int x; };
struct buf * (*rcsopen) (struct buf *, struct stat *, int);
-static char *e (char **p, int i)
+static char *e (p, i)
+ char **p;
+ int i;
{
return p[i];
}
@@ -2113,7 +2115,6 @@ extern int puts (const char *);
extern int printf (const char *, ...);
extern int dprintf (int, const char *, ...);
extern void *malloc (size_t);
-extern void free (void *);
// Check varargs macros. These examples are taken from C99 6.10.3.5.
// dprintf is used instead of fprintf to avoid needing to declare
This appears to be a regression of sorts. I thought the moving away from
the old-style C prototypes in configure tests was needed for newer Clang
versions.
Apologies if this is not an issue.
___
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 6/8] crt: Move fabsf and nexttowardf to libmsvcr*.a for all archs, and to libucrt*.a for x86
On 27/10/2023 16:51, LIU Hao wrote: 在 2023-10-26 19:15, Martin Storsjö 写道: fabsf is available in UCRT on arm32/arm64, but not on x86. nexttowardf is available in UCRT on all architectures, but this functions takes two parameters, and the second parameter is a long ^ There is a typo in this message. Other than that this series of patches look good to me. It looks good to me as well, I'm glad to see those change. Thanks, 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] headers: Restore syncing d3d12.idl from Wine again
On 9/21/23 16:50, LIU Hao wrote: 在 2023-09-20 04:57, Martin Storsjö 写道: The version of d3d12.idl in vkd3d has been completed further now, and has been synced back to Wine; restore mingw-w64-headers to include this header in future syncs from wine. This synchronizes the d3d12.idl header from Wine from commit 6558611fa2d24447297cb62d168b924c33839c43 (but not the other few headers that have been updated there since our last sync). Signed-off-by: Martin Storsjö --- mingw-w64-headers/include/d3d12.idl | 108 mingw-w64-headers/wine-import.sh | 1 + 2 files changed, 109 insertions(+) The change for 'wine-import.sh' looks good to me. Should we include 'd3d12.idl' as well? I think you may do a reimport after updating the script, and the IDL will be overwritten anyway. I think the patch does add d3d12.idl and I think that Martin added d3d12.idl diff to show the impact. Anyway, it looks good to me as well. Thanks, 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 4/4] headers: Add d2d1_2helper.h
Patches look good to me, I pushed to master. Thanks, 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] headers: remove conflicting declarations in qos2.h
Hi, I assume you attached a patch file with the file extension `.patch` but unfortunately it was stripped from the mailing list. (This happens a lot for patches sent from Gmail.) Can you resend it with the file extension changed to `.txt`? Thanks. On 12/9/2023 22:48, Oleg Tolmatcev wrote: Hello, This patch removes declarations that lead to compilation errors in Dolphin. Best regards Oleg ___ 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 2/2] headers: Manually import d3d12.idl from vkd3d
On 9/8/23 13:48, Martin Storsjö wrote: Ideally the d3d12.idl in wine will be brought up to sync at some point, but for now, exclude this header and sync it manually from vkd3d instead. Yes, we will want to re-sync all of that and I'm happy to help with that if needed. The patch itself looks good to me and I'm fine with committing it meantime as is to unblock you. Thanks, 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 1/2] headers: Add the D3D12 shader compiler interface dxcapi.h
On 9/8/23 13:48, Martin Storsjö wrote: This header is appropriately licensed with a compatible open source license, the University of Illinois Open Source License (a BSD-like license). It looks good to me. It's nice to see Microsoft open sourcing at least parts of their SDK. Thanks, 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 2/2] headers: Manually import d3d12.idl from vkd3d
Martin Storsjö writes: > This is the latest version of vkd3d_d3d12.idl from > https://gitlab.winehq.org/wine/vkd3d, plus some additions that still > are under review at > https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/332, with > slight adjustments to the include lines at the top. > > Remove d3d12.idl from the list of files that manually are synced > from main wine, as d3d12.idl there is lacking lots of declarations. > > Ideally the d3d12.idl in wine will be brought up to sync at some point, > but for now, exclude this header and sync it manually from vkd3d > instead. Please feel free to send that same patch to Wine, there's no reason for the headers to be out of sync. -- Alexandre Julliard julli...@winehq.org ___ 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 2/2] headers: Manually import d3d12.idl from vkd3d
Martin Storsjö writes: > On Fri, 8 Sep 2023, Alexandre Julliard wrote: > >> Martin Storsjö writes: >> >>> This is the latest version of vkd3d_d3d12.idl from >>> https://gitlab.winehq.org/wine/vkd3d, plus some additions that still >>> are under review at >>> https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/332, with >>> slight adjustments to the include lines at the top. >>> >>> Remove d3d12.idl from the list of files that manually are synced >>> from main wine, as d3d12.idl there is lacking lots of declarations. >>> >>> Ideally the d3d12.idl in wine will be brought up to sync at some point, >>> but for now, exclude this header and sync it manually from vkd3d >>> instead. >> >> Please feel free to send that same patch to Wine, there's no reason for >> the headers to be out of sync. > > Sure, I can do that. > > They were out of sync already to begin with (vkd3d having mostly more > interfaces implemented, but lacking some few structs, and missing some > CLSID definitions that were present in wine). The headers in vkd3d > were closer to what I wanted (we were missing a bunch of interfaces > needed for building QtBase's D3D12 renderer; vkd3d had most of it but > not all). Yes, they haven't been synced properly for a while, but that's not deliberate, it's just that no one bothered to do it. > Once the reviews within vkd3d have settled, I can try to look into > syncing that header back with wine. Thanks! -- Alexandre Julliard julli...@winehq.org ___ 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] propkeydef.h: Drop include once guards.
On 8/8/23 16:30, LIU Hao wrote: 在 2023-08-08 20:40, Jacek Caban via Mingw-w64-public 写道: Fixes regression from 3638d5e9a6f2 reported: https://bugzilla.mozilla.org/show_bug.cgi?id=1847683 Those guards are not present in Wine and Windows SDK for a reason: if INITGUID is changed, it should be reflected in DEFINE_PROPERTYKEY macro. --- mingw-w64-headers/include/propkeydef.h | 9 - 1 file changed, 9 deletions(-) Oh didn't know that. Thanks for the information. The patch looks good to me. Please go ahead and apply. Pushed, thanks. Jacek ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] [PATCH] propkeydef.h: Drop include once guards.
Fixes regression from 3638d5e9a6f2 reported:
https://bugzilla.mozilla.org/show_bug.cgi?id=1847683
Those guards are not present in Wine and Windows SDK for a reason: if
INITGUID is changed, it should be reflected in DEFINE_PROPERTYKEY macro.
---
mingw-w64-headers/include/propkeydef.h | 9 -
1 file changed, 9 deletions(-)
diff --git a/mingw-w64-headers/include/propkeydef.h
b/mingw-w64-headers/include/propkeydef.h
index d40f284d1..3b7750294 100644
--- a/mingw-w64-headers/include/propkeydef.h
+++ b/mingw-w64-headers/include/propkeydef.h
@@ -5,10 +5,6 @@
*/
-#ifndef PROPKEYDEF_H
-#define PROPKEYDEF_H
-
-
/* This file provides macros and procedures relevant to the
PROPERTYKEY structure defined in wtypes.h. */
@@ -21,9 +17,7 @@
#endif
/* See the definitions of PROPERTYKEY in wtypes.h, and GUID in
guiddef.h. "l" is short for "long", "w" for "word", "b" for "byte", and
"pid" for "property identifier". */
-#if defined(DEFINE_PROPERTYKEY)
#undef DEFINE_PROPERTYKEY
-#endif
#if defined(INITGUID) && defined(__cplusplus)
#define DEFINE_PROPERTYKEY(name,l,w1,w2,b1,b2,b3,b4,b5,b6,b7,b8,pid)
EXTERN_C const PROPERTYKEY DECLSPEC_SELECTANY name =
{{l,w1,w2,{b1,b2,b3,b4,b5,b6,b7,b8}},pid}
#elif defined(INITGUID) && !defined(__cplusplus)
@@ -59,6 +53,3 @@ extern "C++"
}
#endif
#endif
-
-
-#endif /* PROPKEYDEF_H */
--
2.41.0
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] __cpuid and __cpuidex prototypes
Thanks for looking into this. I was kind of intimdated by all the macros in intrin.h, whose meanings were not entirely clear. Like __MACHINEI, I though maybe the "I" stood for "Intel" so anything in a __MACHINEI shouldn't be defined on ARM. On Mon, 31 Jul 2023, LIU Hao wrote: > The declaration for `__cpuidex` on the other hand has never been added, maybe > due to lack of interest; but there are other reasons why we probably don't > want to declare it, explained in d2374f898457b0f4ea8bd4084a94f2dafc87a99a. That's kind of unfortunate. I guess it works out OK though, GCC must be providing it on x86 (and presumably Clang too, for compatibility with GCC). > I think I should propose a patch to hide `__cpuid` for non-x86 targets. I would have done so, except for the macro confusion referenced above I was not sure what else should or should not be present, especially for ia64 which I have never dealt with. ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] __cpuid and __cpuidex prototypes
Recently, a build of pycryptodome failed on MSYS2's CLANGARM64, due to a compile error about __cpuidex not being declared. I know cpuid is an x86 thing, and wouldn't expect it to be present on arm(64). While investigating why this started failing, I found a few things (two of which seem to be issues with mingw-w64). * The prototype for __cpuid in intrin.h is present on ARM64 (and probably ARM32 as well, not tested). This is why the compile test that pycryptodome was doing succeeded (they were only compiling, not linking, or it would have failed at link time) and they went ahead and tried using __cpuidex * pycryptodome's test was checking for __cpuid, but actually ended up using __cpuidex. https://github.com/Legrandin/pycryptodome/pull/757 * There does not appear to be any prototype in intrin.h for __cpuidex like there is for __cpuid, though it is defined in intrin-impl.h. This "oversight" actually allowed the above pull request to sucessfully allow pycryptodome to build for CLANGARM64 (assuming it would have also been erroneously prototyped on ARM as __cpuid was). ___ 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 3/3] headers: Define D2D1FORCEINLINE where needed
On 7/23/23 13:04, LIU Hao wrote: 在 2023-07-23 18:43, Jacek Caban via Mingw-w64-public 写道: The commit is missing some files generated from IDLs, so current tree doesn't build. I tried building headers and regenerated all of them from IDL. It was necessary to use an up-to-date WIDL, but I didn't find any missing files..? Those were missing: d2d1_2.h, d2d1_3.h, d2d1effects_1.h and d2d1effects_2.h and they are included from uuid.c. Even more importantly, D2D headers have a lot of C++ features, like inline function helpers that overload virtual functions, that are not expressed in Wine IDLs. There is a reason why MS doesn't use IDLs for D2D and it's the same reason we never imported those IDLs. That makes IDLs very incompatible with Windows SDK headers. Those patches broke Firefox build in multiple ways. It should be possible to share more of D2D between Wine and mingw-w64, but not without more work, careful consideration and proper review. I feel like all of that was missing in this case. Anyway, given that the whole series is just plain wrong, I suggest to revert it all. OK, reverted now. Thanks. As Firefox is mentioned, maybe someone can test building Firefox with 73526385645ffa35c03c0d473b7eac0e00d94541 and see. I tried wine-gecko (a Firefox 47 fork) and it failed in multiple places as expected. The main blockers are overloaded inline helpers. If anyone is interested, building wine-gecko on Linux is as easy as running ./wine/make_package from https://gitlab.winehq.org/wine/wine-gecko.git (it should be also possible to build more recent Firefox, but that's more tricky). 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 3/3] headers: Define D2D1FORCEINLINE where needed
On 7/23/23 11:58, LIU Hao wrote: 在 2023-07-23 13:57, Biswapriyo Nath 写道: From 2a64bfe452a92a5197b2e102f5d46c28d14a7631 Mon Sep 17 00:00:00 2001 From: Biswapriyo Nath Date: Sun, 23 Jul 2023 11:17:05 +0530 Subject: [PATCH 3/3] headers: Define D2D1FORCEINLINE where needed Signed-off-by: Biswapriyo Nath --- mingw-w64-headers/include/d2d1_1helper.h | 4 mingw-w64-headers/include/d2d1helper.h | 4 2 files changed, 8 insertions(+) Thanks for the patches. Pushed to master now. The commit is missing some files generated from IDLs, so current tree doesn't build. Even more importantly, D2D headers have a lot of C++ features, like inline function helpers that overload virtual functions, that are not expressed in Wine IDLs. There is a reason why MS doesn't use IDLs for D2D and it's the same reason we never imported those IDLs. That makes IDLs very incompatible with Windows SDK headers. Those patches broke Firefox build in multiple ways. It should be possible to share more of D2D between Wine and mingw-w64, but not without more work, careful consideration and proper review. I feel like all of that was missing in this case. Anyway, given that the whole series is just plain wrong, I suggest to revert it all. Jacek ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] mingw-w64 uses UCRT by default now.
Hi all, I just pushed a change to out build system to use UCRT by default. Bellow is a copy of more detailed informations, it can be also found in git in mingw-w64-doc/howto-build/ucrt-vs-msvcrt.txt. Thanks, Jacek == Summary == Starting from mingw-w64 version 12 and onwards, UCRT (Universal C Runtime) will be the default CRT runtime, unless specified otherwise during the minwgw-64 build process. We believe that this configuration is the best choice for the majority of users. While we encourage users to consider switching to UCRT, we understand that it may not always be desirable, especially for compatibility reasons. Therefore, all previously supported configurations will continue to be supported. Users who wish to continue using msvcrt.dll can easily do so by adding the --with-default-msvcrt=msvcrt argument to both the mingw-w64-headers and mingw-w64-crt configure scripts. == Background == mingw-w64 provides C runtime libraries that directly or indirectly utilize Microsoft DLLs at runtime. Over the years, Microsoft has released various versions of these DLLs, some of which were designed for specific MSVC versions while others aimed for backward compatibility. When building the mingw-w64 toolchain, users can specify a version of the runtime DLL using the --with-default-msvcrt= configure option. The most commonly used versions are ucrt (utilizing ucrtbase.dll) and msvcrt (utilizing msvcrt.dll). The implementation of msvcrt.dll dates back to the Windows 9x era. While it has been extended for a period, it eventually became frozen in favor of providing separate DLLs for future MSVC versions. Although msvcrt.dll continues to be shipped with modern Windows versions, it remains compatible with the version from the 1990s. msvcrt.dll is known to deviate from standard behavior in many aspects. mingw-w64 includes compatibility wrappers and extensions to improve standard compatibility, but there are limitations to what can be practically achieved. On the other hand, ucrtbase.dll was introduced with MSVC 14 and is currently included with all Windows versions supported by Microsoft. It is also available as a redistributable package for older versions of Windows. ucrtbase.dll aims to replace MSVC version-specific DLLs and has been used by all MSVC versions since its introduction. It offers a more modern approach compared to msvcrt.dll and provides better standard compatibility out of the box, reducing overhead on the mingw-w64 side. == Compatibility == When switching between toolchains that use different runtime libraries, it is generally advised not to mix static libraries, unless certain exceptions apply. If in doubt, it is recommended to rebuild all static libraries when switching the toolchain's runtime DLL. Dynamic libraries are less likely to be affected. If the CRT is not part of the ABI of a library you intend to use, meaning it does not involve passing FILE structs or similar types between modules or depending on the CRT allocator of other modules, it should remain unaffected. Otherwise, a compatible build of that library will be required. == See Also == "MSVCRT vs UCRT": https://www.msys2.org/docs/environments/ ___ 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 v3] configure: Use ucrt for msvcrt by default.
On 6/25/23 16:32, LIU Hao wrote: 在 2023-06-19 20:43, Jacek Caban via Mingw-w64-public 写道: --- mingw-w64-crt/configure.ac | 4 +- mingw-w64-doc/howto-build/ucrt-vs-msvcrt.txt | 58 mingw-w64-headers/configure.ac | 12 ++-- 3 files changed, 66 insertions(+), 8 deletions(-) create mode 100644 mingw-w64-doc/howto-build/ucrt-vs-msvcrt.txt Provided there is no objection, I'm okay with this change. Thanks. I pushed the patch. I will send a separate mail to ML for better visibility. 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 1/2] headers: Add wia.idl
On 6/20/23 20:27, Biswapriyo Nath wrote: Is it possible to provide any hit why the widl crashed? Or is there any way to troubleshoot the issue? You may incrementally revert parts of your changes until it works. It should give a good idea where to look. Please file a bug if you need more assistance. 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 1/2] headers: Add wia.idl
On 6/20/23 19:39, Biswapriyo Nath wrote: Is it possible to add the file in mingw-w64? It has been a week and I get no response in wine merge request. It crashes widl during the build, so it's pretty obvious why it's not merged. Jacek ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] [PATCH v3] configure: Use ucrt for msvcrt by default.
--- mingw-w64-crt/configure.ac | 4 +- mingw-w64-doc/howto-build/ucrt-vs-msvcrt.txt | 58 mingw-w64-headers/configure.ac | 12 ++-- 3 files changed, 66 insertions(+), 8 deletions(-) create mode 100644 mingw-w64-doc/howto-build/ucrt-vs-msvcrt.txt diff --git a/mingw-w64-crt/configure.ac b/mingw-w64-crt/configure.ac index 05f40b261..ced7745ca 100644 --- a/mingw-w64-crt/configure.ac +++ b/mingw-w64-crt/configure.ac @@ -267,9 +267,9 @@ AC_MSG_RESULT([$enable_delay_import_libs]) AC_MSG_CHECKING([what to provide as libmsvcrt.a]) AC_ARG_WITH([default-msvcrt], [AS_HELP_STRING([--with-default-msvcrt=LIB], -[Lib to provide as libmsvcrt.a (default: msvcrt-os)])], +[Lib to provide as libmsvcrt.a (default: ucrt)])], [], - [with_default_msvcrt=msvcrt-os]) + [with_default_msvcrt=ucrt]) if test "$with_default_msvcrt" = "msvcrt"; then with_default_msvcrt=msvcrt-os fi diff --git a/mingw-w64-doc/howto-build/ucrt-vs-msvcrt.txt b/mingw-w64-doc/howto-build/ucrt-vs-msvcrt.txt new file mode 100644 index 0..3cc3329ad --- /dev/null +++ b/mingw-w64-doc/howto-build/ucrt-vs-msvcrt.txt @@ -0,0 +1,58 @@ +== Summary == + +Starting from mingw-w64 version 12 and onwards, UCRT (Universal C Runtime) will +be the default CRT runtime, unless specified otherwise during the minwgw-64 +build process. We believe that this configuration is the best choice for the +majority of users. While we encourage users to consider switching to UCRT, we +understand that it may not always be desirable, especially for compatibility +reasons. Therefore, all previously supported configurations will continue to +be supported. Users who wish to continue using msvcrt.dll can easily do so by +adding the --with-default-msvcrt=msvcrt argument to both the +mingw-w64-headers and mingw-w64-crt configure scripts. + + +== Background == + +mingw-w64 provides C runtime libraries that directly or indirectly utilize +Microsoft DLLs at runtime. Over the years, Microsoft has released various +versions of these DLLs, some of which were designed for specific MSVC versions +while others aimed for backward compatibility. When building the mingw-w64 +toolchain, users can specify a version of the runtime DLL using the +--with-default-msvcrt= configure option. The most commonly used versions are +ucrt (utilizing ucrtbase.dll) and msvcrt (utilizing msvcrt.dll). + +The implementation of msvcrt.dll dates back to the Windows 9x era. While it has +been extended for a period, it eventually became frozen in favor of providing +separate DLLs for future MSVC versions. Although msvcrt.dll continues to be +shipped with modern Windows versions, it remains compatible with the version +from the 1990s. msvcrt.dll is known to deviate from standard behavior in many +aspects. mingw-w64 includes compatibility wrappers and extensions to improve +standard compatibility, but there are limitations to what can be practically +achieved. + +On the other hand, ucrtbase.dll was introduced with MSVC 14 and is currently +included with all Windows versions supported by Microsoft. It is also available +as a redistributable package for older versions of Windows. ucrtbase.dll aims to +replace MSVC version-specific DLLs and has been used by all MSVC versions since +its introduction. It offers a more modern approach compared to msvcrt.dll and +provides better standard compatibility out of the box, reducing overhead on the +mingw-w64 side. + + +== Compatibility == + +When switching between toolchains that use different runtime libraries, it is +generally advised not to mix static libraries, unless certain exceptions apply. +If in doubt, it is recommended to rebuild all static libraries when switching +the toolchain's runtime DLL. + +Dynamic libraries are less likely to be affected. If the CRT is not part of the +ABI of a library you intend to use, meaning it does not involve passing FILE +structs or similar types between modules or depending on the CRT allocator of +other modules, it should remain unaffected. Otherwise, a compatible build of +that library will be required. + + +== See Also == + +"MSVCRT vs UCRT": https://www.msys2.org/docs/environments/ diff --git a/mingw-w64-headers/configure.ac b/mingw-w64-headers/configure.ac index d82280cd7..d6809d147 100644 --- a/mingw-w64-headers/configure.ac +++ b/mingw-w64-headers/configure.ac @@ -144,9 +144,9 @@ AC_SUBST([DEFAULT_WIN32_WINNT]) AC_MSG_CHECKING([default msvcrt]) AC_ARG_WITH([default-msvcrt], [AS_HELP_STRING([--with-default-msvcrt=LIB], -[Default msvcrt to target (default: msvcrt)])], +[Default msvcrt to target (default: ucrt)])], [], - [with_default_msvcrt=msvcrt]) + [with_default_msvcrt=ucrt]) case $with_default_msvcrt in msvcrt10*) default_msvcrt_version=0x100 @@ -178,12 +178,12 @@ msvcr110*) msvcr120*) default_msvcrt_version=0xC00 ;; -ucrt*) - default_msvcrt_version=0xE00 - ;; -msvcrt|*) +msvcrt*) default_ms
Re: [Mingw-w64-public] [PATCH v2] configure: Use ucrt for msvcrt by default.
On 6/19/23 14:20, Martin Storsjö wrote: On Mon, 19 Jun 2023, Jacek Caban via Mingw-w64-public wrote: v2 includes changes suggested by Martin. It also includes a documentation change to clarify the situation. --- mingw-w64-crt/configure.ac | 4 +- mingw-w64-doc/howto-build/ucrt-vs-msvcrt.txt | 58 mingw-w64-headers/configure.ac | 12 ++-- 3 files changed, 66 insertions(+), 8 deletions(-) create mode 100644 mingw-w64-doc/howto-build/ucrt-vs-msvcrt.txt +be supported. Users who wish to continue using msvcrt.dll can easily do so by +adding the --with-default-msvcrt=msvcrt-os argument to both the +mingw-w64-headers and mingw-w64-crt configure scripts. Actually, you can do just --with-default-msvcrt=msvcrt - the distinction between msvcrt vs msvcrt-os is handled within mingw-w64-crt/configure.ac - so we don't need to expose that detail to users in this doc. Same thing in the paragraph below, we could just name it "msvcrt" there. Oh, right, that's better. I sent a new version with suggested changes. Thanks, Jacek ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] [PATCH v2] configure: Use ucrt for msvcrt by default.
v2 includes changes suggested by Martin. It also includes a documentation change to clarify the situation. --- mingw-w64-crt/configure.ac | 4 +- mingw-w64-doc/howto-build/ucrt-vs-msvcrt.txt | 58 mingw-w64-headers/configure.ac | 12 ++-- 3 files changed, 66 insertions(+), 8 deletions(-) create mode 100644 mingw-w64-doc/howto-build/ucrt-vs-msvcrt.txt diff --git a/mingw-w64-crt/configure.ac b/mingw-w64-crt/configure.ac index 05f40b261..ced7745ca 100644 --- a/mingw-w64-crt/configure.ac +++ b/mingw-w64-crt/configure.ac @@ -267,9 +267,9 @@ AC_MSG_RESULT([$enable_delay_import_libs]) AC_MSG_CHECKING([what to provide as libmsvcrt.a]) AC_ARG_WITH([default-msvcrt], [AS_HELP_STRING([--with-default-msvcrt=LIB], -[Lib to provide as libmsvcrt.a (default: msvcrt-os)])], +[Lib to provide as libmsvcrt.a (default: ucrt)])], [], - [with_default_msvcrt=msvcrt-os]) + [with_default_msvcrt=ucrt]) if test "$with_default_msvcrt" = "msvcrt"; then with_default_msvcrt=msvcrt-os fi diff --git a/mingw-w64-doc/howto-build/ucrt-vs-msvcrt.txt b/mingw-w64-doc/howto-build/ucrt-vs-msvcrt.txt new file mode 100644 index 0..445b8a067 --- /dev/null +++ b/mingw-w64-doc/howto-build/ucrt-vs-msvcrt.txt @@ -0,0 +1,58 @@ +== Summary == + +Starting from mingw-w64 version 12 and onwards, UCRT (Universal C Runtime) will +be the default CRT runtime, unless specified otherwise during the minwgw-64 +build process. We believe that this configuration is the best choice for the +majority of users. While we encourage users to consider switching to UCRT, we +understand that it may not always be desirable, especially for compatibility +reasons. Therefore, all previously supported configurations will continue to +be supported. Users who wish to continue using msvcrt.dll can easily do so by +adding the --with-default-msvcrt=msvcrt-os argument to both the +mingw-w64-headers and mingw-w64-crt configure scripts. + + +== Background == + +mingw-w64 provides C runtime libraries that directly or indirectly utilize +Microsoft DLLs at runtime. Over the years, Microsoft has released various +versions of these DLLs, some of which were designed for specific MSVC versions +while others aimed for backward compatibility. When building the mingw-w64 +toolchain, users can specify a version of the runtime DLL using the +--with-default-msvcrt= configure option. The most commonly used versions are +ucrt (utilizing ucrtbase.dll) and msvcrt-os (utilizing msvcrt.dll). + +The implementation of msvcrt.dll dates back to the Windows 9x era. While it has +been extended for a period, it eventually became frozen in favor of providing +separate DLLs for future MSVC versions. Although msvcrt.dll continues to be +shipped with modern Windows versions, it remains compatible with the version +from the 1990s. msvcrt.dll is known to deviate from standard behavior in many +aspects. mingw-w64 includes compatibility wrappers and extensions to improve +standard compatibility, but there are limitations to what can be practically +achieved. + +On the other hand, ucrtbase.dll was introduced with MSVC 14 and is currently +included with all Windows versions supported by Microsoft. It is also available +as a redistributable package for older versions of Windows. ucrtbase.dll aims to +replace MSVC version-specific DLLs and has been used by all MSVC versions since +its introduction. It offers a more modern approach compared to msvcrt.dll and +provides better standard compatibility out of the box, reducing overhead on the +mingw-w64 side. + + +== Compatibility == + +When switching between toolchains that use different runtime libraries, it is +generally advised not to mix static libraries, unless certain exceptions apply. +If in doubt, it is recommended to rebuild all static libraries when switching +the toolchain's runtime DLL. + +Dynamic libraries are less likely to be affected. If the CRT is not part of the +ABI of a library you intend to use, meaning it does not involve passing FILE +structs or similar types between modules or depending on the CRT allocator of +other modules, it should remain unaffected. Otherwise, a compatible build of +that library will be required. + + +== See Also == + +"MSVCRT vs UCRT": https://www.msys2.org/docs/environments/ \ No newline at end of file diff --git a/mingw-w64-headers/configure.ac b/mingw-w64-headers/configure.ac index d82280cd7..d6809d147 100644 --- a/mingw-w64-headers/configure.ac +++ b/mingw-w64-headers/configure.ac @@ -144,9 +144,9 @@ AC_SUBST([DEFAULT_WIN32_WINNT]) AC_MSG_CHECKING([default msvcrt]) AC_ARG_WITH([default-msvcrt], [AS_HELP_STRING([--with-default-msvcrt=LIB], -[Default msvcrt to target (default: msvcrt)])], +[Default msvcrt to target (default: ucrt)])], [], - [with_default_msvcrt=msvcrt]) + [with_default_msvcrt=ucrt]) case $with_default_msvcrt in msvcrt10*) default_msvcrt_version=0x100 @@ -178,12 +
[Mingw-w64-public] [PATCH] Fix reference counting bug in Microsoft::WRL::ComPtr::Attach
From 47baf71618146b3fd5fc6ec92c326acb9a026cce Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?J=C3=B8ger=20Hanseg=C3=A5rd?=
Date: Fri, 16 Jun 2023 11:08:00 +0200
Subject: [PATCH] Fix reference counting bug in Microsoft::WRL::ComPtr::Attach
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Microsoft::WRL::ComPtr::Attach should take ownership of an interface and
must therefore not increment the reference count of the attached
interface pointer.
This patch fixes this issue, and makes the MINGW64 implementation
behave the same way as the implementation shipped with the Microsoft
SDK.
Fixes: #892 Microsoft::WRL::ComPtr::Attach leaks references
Signed-off-by: Jøger Hansegård
---
mingw-w64-headers/include/wrl/client.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/mingw-w64-headers/include/wrl/client.h
b/mingw-w64-headers/include/wrl/client.h
index 12239e108..aeb886ea8 100644
--- a/mingw-w64-headers/include/wrl/client.h
+++ b/mingw-w64-headers/include/wrl/client.h
@@ -206,7 +206,6 @@ namespace Microsoft {
if (ptr_ != other) {
InternalRelease();
ptr_ = other;
-InternalAddRef();
}
}
--
2.40.1.windows.1
___
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] configure: Use ucrt for msvcrt by default.
On 6/8/23 06:18, LIU Hao wrote: I agree that those are valid concerns. However, there is little we can do about it and it's unlikely to change over time. Do we want msvcrt-os to remain the default forever? For your information, this is a non-exhaustive list of distributions that do not specify `--with-default-msvcrt` and will be affected: * Debian: https://sources.debian.org/src/mingw-w64/10.0.0-3/debian/rules/#L131 * Ubuntu (likely): https://launchpad.net/ubuntu/+source/mingw-w64/10.0.0-3 * ArchLinux: https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=mingw-w64-crt-git#n49 * w64devkit: https://github.com/skeeto/w64devkit/blob/2617b474334610abb7e82fc12f656abb3622723f/Dockerfile#L219 I think that those are well maintained packages and asking them for one extra configure argument if they want to continue using msvcrt.dll is not much (although I think that at least some of them would be happy switching to UCRT by doing nothing). We'd not be taking anything away, just asking to be a bit more explicit about it. I guess that those are examples of users that were happy with defaults when packages were created and left it that way. The point of the change is that future packages that similarly leave the decision to us (implicitly, by using configure defaults) will use currently recommended settings. Thanks, 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] crt: add some missing CRT entries
Martin Storsjö writes: > On Thu, 8 Jun 2023, Alexandre Julliard wrote: > >> Martin Storsjö writes: >> >>> When looking at the redistributable api-ms-win-crt*.dlls from the >>> redistributable UCRT, api-ms-win-crt-filesystem-l1-1-0.dll does not >>> contain these symbols; neither in the original releases of UCRT from >>> 2015, nor in the current releases from the latest WinSDK. So if we >>> link against this function from api-ms-win-crt-filesystem-l1-1-0.dll, >>> a binary won't load with the redistributable version of UCRT. >>> >>> As these DLLs don't exist physically on disk in actual Windows 10, I >>> can't inspect that, but I did try to link a test executable with this, >>> which imports _getcwd from api-ms-win-crt-filesystem-l1-1-0.dll and it >>> actually does seem to run successfully on Windows 10, so it is >>> somewhat there still. >> >> Note that at runtime, imports of api-ms-* dlls are not resolved like >> normal imports; first the dll name is mapped to the target dll through >> the apiset data, and then the function is looked up in the target dll >> only. The function is never actually looked up in the api-ms-* dll. >> >> This means that the fact that a function is found on Windows at runtime >> doesn't tell you anything about whether it should be in the api-ms-* >> importlib. > > Thanks, I didn't know that aspect! > >> It also means that there's no issue with having the same function >> exported from multiple api-ms-win-crt-* importlibs, or with having extra >> exports that may not exist on Windows. All that matters at runtime is >> that the function can be found in ucrtbase.dll. > > Except that for older OSes, the UCRT is a separate redistributable > install and not handled as OS-provided apisets. > > My test executable, which imported _getcwd from > api-ms-win-crt-filesystem-l1-1-0.dll, which succeeded on Windows 10, > failed to load on Windows 7 (with UCRT installed), while a similar > executable linked with the current git version of import libs did load > successfully. Good point, indeed the redistributable is using plain forwards instead of apisets, so in that case the imports have to match exactly. -- Alexandre Julliard julli...@winehq.org ___ 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] crt: add some missing CRT entries
Martin Storsjö writes: > When looking at the redistributable api-ms-win-crt*.dlls from the > redistributable UCRT, api-ms-win-crt-filesystem-l1-1-0.dll does not > contain these symbols; neither in the original releases of UCRT from > 2015, nor in the current releases from the latest WinSDK. So if we > link against this function from api-ms-win-crt-filesystem-l1-1-0.dll, > a binary won't load with the redistributable version of UCRT. > > As these DLLs don't exist physically on disk in actual Windows 10, I > can't inspect that, but I did try to link a test executable with this, > which imports _getcwd from api-ms-win-crt-filesystem-l1-1-0.dll and it > actually does seem to run successfully on Windows 10, so it is > somewhat there still. Note that at runtime, imports of api-ms-* dlls are not resolved like normal imports; first the dll name is mapped to the target dll through the apiset data, and then the function is looked up in the target dll only. The function is never actually looked up in the api-ms-* dll. This means that the fact that a function is found on Windows at runtime doesn't tell you anything about whether it should be in the api-ms-* importlib. All the api-ms-win-crt-* dlls resolve to ucrtbase.dll, so you could import _getcwd (or any other ucrtbase.dll function) from any of the api-ms-win-crt-* dlls and it will load correctly on Windows. It also means that there's no issue with having the same function exported from multiple api-ms-win-crt-* importlibs, or with having extra exports that may not exist on Windows. All that matters at runtime is that the function can be found in ucrtbase.dll. -- Alexandre Julliard julli...@winehq.org ___ 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 1/2] headers: Add wia.idl
On 6/7/23 19:46, Biswapriyo Nath wrote: Do we need to reimplement 'wia.idl', instead of importing 'wia_lh.idl' and 'wia_xp.idl' from Wine? wia_lh.idl and wia_xp.idl in wine are missing many declarations. It should be easy to add them to Wine. Besides, wia_xp.h is just a stripped down version of wia_lh.h in Windows SDK. So, adding just wia.idl is good enough. Compatibility with Windows SDK seems better, otherwise we'd miss support for things like "#include ". 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] configure: Use ucrt for msvcrt by default.
On 6/5/23 10:59, Martin Storsjö wrote: On Sun, 4 Jun 2023, Jacek Caban via Mingw-w64-public wrote: We're early in release cycle again, so it feels like a good time to consider defaulting to ucrt. At this point, ucrt support seems generally mature enough and I'm not aware of any blockers. Yes, this is probably true in general. Changing the default probably is fine for anyone setting up a new toolchain from scratch. But for people upgrading the mingw-w64 bits on an existing toolchain in place, this would be very disruptive and break things, unless everybody already were specifying what CRT they want to use (when this wouldn't make any difference). I'm not sure how common this is though. In something like a msys2 style environment, I would expect this to happen semi-regularly though (although msys2 users probably leave this up to the package manager instead of doing it themselves). So like LH, I'm a little bit concerned about the potential disruptiveness of this change. I agree that those are valid concerns. However, there is little we can do about it and it's unlikely to change over time. Do we want msvcrt-os to remain the default forever? On the other hand, it would give a clear signal about the direction and what we suggest, and anybody can still revert to the old behaviour by just passing the configure option. Yes, I think that at this point UCRT became de facto recommended configuration. We provide tools to build UCRT toolchains and suggest people to use it so there already is a mixture of ABIs in the wild. A little push in UCRT direction would be good in my opinion. I also think that it's fair to expect default configure option to reflect recommended setup. And yes, --with-default-msvcrt=msvcrt-os is not going anywhere, so it's just one configure option away for users that want it. The problem is that people would need to be aware of it, etc. We'd want to be very verbose in release notes and I may send a notice to ML. I'm not sure there is more we can do. Also note that on Windows, dealing with multiple CRTs and their incompatibilities is not that uncommon. MSVC forced that with each new version for a long time. Changing the default once and keeping an option to be compatible with chosen version doesn't seem too bad in comparison ;) For the concrete patch, I've got one suggestion: @@ -178,12 +178,12 @@ msvcr110*) msvcr120*) default_msvcrt_version=0xC00 ;; -ucrt*) - default_msvcrt_version=0xE00 - ;; -msvcrt|*) +msvcrt*) default_msvcrt_version=0x700 ;; +*) + default_msvcrt_version=0xE00 + ;; I think it'd be more readable if we'd keep the last case statement as ucrt*|*) While the * would match it anyway and it's quite redundant, it serves as a label for what the case is for. Sounds good, I will change it if we decide to proceed. Thanks, Jacek ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] [PATCH] configure: Use ucrt for msvcrt by default.
Hi all, We're early in release cycle again, so it feels like a good time to consider defaulting to ucrt. At this point, ucrt support seems generally mature enough and I'm not aware of any blockers. Thanks, Jacek --- mingw-w64-crt/configure.ac | 4 ++-- mingw-w64-headers/configure.ac | 12 ++-- 2 files changed, 8 insertions(+), 8 deletions(-) diff --git a/mingw-w64-crt/configure.ac b/mingw-w64-crt/configure.ac index 05f40b261..ced7745ca 100644 --- a/mingw-w64-crt/configure.ac +++ b/mingw-w64-crt/configure.ac @@ -267,9 +267,9 @@ AC_MSG_RESULT([$enable_delay_import_libs]) AC_MSG_CHECKING([what to provide as libmsvcrt.a]) AC_ARG_WITH([default-msvcrt], [AS_HELP_STRING([--with-default-msvcrt=LIB], -[Lib to provide as libmsvcrt.a (default: msvcrt-os)])], +[Lib to provide as libmsvcrt.a (default: ucrt)])], [], - [with_default_msvcrt=msvcrt-os]) + [with_default_msvcrt=ucrt]) if test "$with_default_msvcrt" = "msvcrt"; then with_default_msvcrt=msvcrt-os fi diff --git a/mingw-w64-headers/configure.ac b/mingw-w64-headers/configure.ac index d82280cd7..f4bf68fa1 100644 --- a/mingw-w64-headers/configure.ac +++ b/mingw-w64-headers/configure.ac @@ -144,9 +144,9 @@ AC_SUBST([DEFAULT_WIN32_WINNT]) AC_MSG_CHECKING([default msvcrt]) AC_ARG_WITH([default-msvcrt], [AS_HELP_STRING([--with-default-msvcrt=LIB], -[Default msvcrt to target (default: msvcrt)])], +[Default msvcrt to target (default: ucrt)])], [], - [with_default_msvcrt=msvcrt]) + [with_default_msvcrt=ucrt]) case $with_default_msvcrt in msvcrt10*) default_msvcrt_version=0x100 @@ -178,12 +178,12 @@ msvcr110*) msvcr120*) default_msvcrt_version=0xC00 ;; -ucrt*) - default_msvcrt_version=0xE00 - ;; -msvcrt|*) +msvcrt*) default_msvcrt_version=0x700 ;; +*) + default_msvcrt_version=0xE00 + ;; esac AC_MSG_RESULT([$with_default_msvcrt ($default_msvcrt_version)]) AS_VAR_SET([DEFAULT_MSVCRT_VERSION],[$default_msvcrt_version]) ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] headers: Add a few more C++ overloads.
Hello list,
please find attached some patches to add a few more C++ overloads.
Kind regards,
BernhardFrom 226a8b26af43fe07928a7151dc6d168b4a26701d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Bernhard=20=C3=9Cbelacker?=
Date: Wed, 17 May 2023 23:13:39 +0200
Subject: headers: Remove semicolon from a few C++ overloads in string_s.h
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Signed-off-by: Bernhard Übelacker
---
mingw-w64-headers/crt/sec_api/string_s.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/mingw-w64-headers/crt/sec_api/string_s.h
b/mingw-w64-headers/crt/sec_api/string_s.h
index d62ca8aba..9ec8147b2 100644
--- a/mingw-w64-headers/crt/sec_api/string_s.h
+++ b/mingw-w64-headers/crt/sec_api/string_s.h
@@ -47,7 +47,7 @@ extern "C" {
_CRTIMP errno_t __cdecl strncpy_s(char *_Dst, size_t _DstSizeInChars, const
char *_Src, size_t _MaxCount);
__DEFINE_CPP_OVERLOAD_SECURE_FUNC_0_2(errno_t, strncpy_s, char, _Dest, const
char *, _Source, size_t, _MaxCount)
_CRTIMP errno_t __cdecl _strncpy_s_l(char *_Dst, size_t _DstSizeInChars,
const char *_Src, size_t _MaxCount, _locale_t _Locale);
- __DEFINE_CPP_OVERLOAD_SECURE_FUNC_0_3(errno_t, _strncpy_s_l, char, _Dest,
const char *, _Source, size_t, _MaxCount, _locale_t, _Locale);
+ __DEFINE_CPP_OVERLOAD_SECURE_FUNC_0_3(errno_t, _strncpy_s_l, char, _Dest,
const char *, _Source, size_t, _MaxCount, _locale_t, _Locale)
_CRTIMP char *__cdecl strtok_s(char *_Str,const char *_Delim,char
**_Context);
_CRTIMP char *__cdecl _strtok_s_l(char *_Str,const char *_Delim,char
**_Context,_locale_t _Locale);
_CRTIMP errno_t __cdecl strcat_s(char *_Dst, rsize_t _SizeInBytes, const
char * _Src);
@@ -84,9 +84,9 @@ extern "C" {
_CRTIMP errno_t __cdecl _wcsncat_s_l(wchar_t *_Dst,size_t
_DstSizeInChars,const wchar_t *_Src,size_t _MaxCount,_locale_t _Locale);
__DEFINE_CPP_OVERLOAD_SECURE_FUNC_0_3(errno_t, _wcsncat_s_l, wchar_t, _Dst,
const wchar_t *, _Src, size_t, _MaxCount, _locale_t, _Locale)
_CRTIMP errno_t __cdecl wcsncpy_s(wchar_t *_Dst, size_t _DstSizeInChars,
const wchar_t *_Src, size_t _MaxCount);
- __DEFINE_CPP_OVERLOAD_SECURE_FUNC_0_2(errno_t, wcsncpy_s, wchar_t, _Dest,
const wchar_t *, _Source, size_t, _MaxCount);
+ __DEFINE_CPP_OVERLOAD_SECURE_FUNC_0_2(errno_t, wcsncpy_s, wchar_t, _Dest,
const wchar_t *, _Source, size_t, _MaxCount)
_CRTIMP errno_t __cdecl _wcsncpy_s_l(wchar_t *_Dst, size_t _DstSizeInChars,
const wchar_t *_Src, size_t _MaxCount, _locale_t _Locale);
- __DEFINE_CPP_OVERLOAD_SECURE_FUNC_0_3(errno_t, _wcsncpy_s_l, wchar_t, _Dest,
const wchar_t *, _Source, size_t, _MaxCount, _locale_t, _Locale);
+ __DEFINE_CPP_OVERLOAD_SECURE_FUNC_0_3(errno_t, _wcsncpy_s_l, wchar_t, _Dest,
const wchar_t *, _Source, size_t, _MaxCount, _locale_t, _Locale)
_CRTIMP wchar_t *__cdecl _wcstok_s_l(wchar_t *_Str,const wchar_t
*_Delim,wchar_t **_Context,_locale_t _Locale);
_CRTIMP errno_t __cdecl _wcsset_s_l(wchar_t *_Str,size_t
_SizeInChars,wchar_t _Val,_locale_t _Locale);
__DEFINE_CPP_OVERLOAD_SECURE_FUNC_0_2(errno_t, _wcsset_s_l, wchar_t, _Str,
wchar_t, _Val, _locale_t, _Locale)
--
2.39.2
From 37c3c9c0f1b54238a93442912de2d9b01e8a7f65 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Bernhard=20=C3=9Cbelacker?=
Date: Wed, 17 May 2023 23:25:51 +0200
Subject: headers: Add C++ overload for wcsncat_s in string_s.h
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Signed-off-by: Bernhard Übelacker
---
mingw-w64-headers/crt/sec_api/string_s.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/mingw-w64-headers/crt/sec_api/string_s.h
b/mingw-w64-headers/crt/sec_api/string_s.h
index 9ec8147b2..96a1c4c76 100644
--- a/mingw-w64-headers/crt/sec_api/string_s.h
+++ b/mingw-w64-headers/crt/sec_api/string_s.h
@@ -81,6 +81,7 @@ extern "C" {
__DEFINE_CPP_OVERLOAD_SECURE_FUNC_0_1(errno_t, wcscat_s, wchar_t, _Dest,
const wchar_t *, _Source)
_CRTIMP errno_t __cdecl wcsncat_s(wchar_t *_Dst,size_t _DstSizeInChars,const
wchar_t *_Src,size_t _MaxCount);
+ __DEFINE_CPP_OVERLOAD_SECURE_FUNC_0_2(errno_t, wcsncat_s, wchar_t, _Dst,
const wchar_t *, _Src, size_t, _MaxCount)
_CRTIMP errno_t __cdecl _wcsncat_s_l(wchar_t *_Dst,size_t
_DstSizeInChars,const wchar_t *_Src,size_t _MaxCount,_locale_t _Locale);
__DEFINE_CPP_OVERLOAD_SECURE_FUNC_0_3(errno_t, _wcsncat_s_l, wchar_t, _Dst,
const wchar_t *, _Src, size_t, _MaxCount, _locale_t, _Locale)
_CRTIMP errno_t __cdecl wcsncpy_s(wchar_t *_Dst, size_t _DstSizeInChars,
const wchar_t *_Src, size_t _MaxCount);
--
2.39.2
From 1caebbb6c05b72997f47215f1d818e77d4d73a6a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Bernhard=20=C3=9Cbelacker?=
Date: Wed, 17 May 2023 23:22:05 +0200
Subject: headers: Add C++ overload for _makepath_s in stdlib_s.h.
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Signed-off-by: Bernhard Übelack
Re: [Mingw-w64-public] [PATCH] crt: Reimplement `dirname()` and `basename()`
On 5/11/23 14:52, LIU Hao wrote:
在 2023-04-28 09:47, LIU Hao 写道:
在 2023/4/2 22:00, LIU Hao 写道:
This is a revised patch basing on that.
`do_get_path_info()` now contains no half-way return statement. The
generic code below already handles empty paths.
For UNC paths, the first two components are taken as the prefix,
which means `\\.\C:` and
`\\.\Volume{b75e2c83----602f}` are now handled
universally. DOS drive letters are parsed only as a special case for
non-UNC paths.
Ping?
Ping again?
I'm guessing dirname is not threadsafe? No objections if that is a known
limitation.
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Linking with -lcomtl32 causes WinMain to never be called
This page contains an example of said manifest: https://learn.microsoft.com/en-us/windows/win32/controls/cookbook-overview On 8/5/2023 18:07, LIU Hao wrote: 在 2023/5/8 17:46, Maarten ten Velden 写道: The following should output atleast a (the LoadIconMetric call here is improper usage), but it doesn't even output a. Commenting out LoadIconMetric causes a to be output. The problem thus must be linking LoadIconMetric? You need to load another version of COMCTL32.DLL, since the default one doesn't have that function. There is some information on this answer [1]. Unfortunately, GCC doesn't accept this #pragma thing and you will have to provide the manifest as an XML resource. [1] https://social.msdn.microsoft.com/Forums/en-US/722193a4-7fba-4ed9-a41f-6629efdb2a78/loadiconmetric-corresponding-ordinal-number-380-could-not-be-located?forum=vcgeneral ___ 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] Exported symbols of import .lib are influenced by the .def file
On Thu, 4 May 2023, Kacvinsky, Tom wrote: > I cloned the repo and built with mingw-w64 x86, but used __cdecl instead of > __stdcall. The import library had the right name decoration for x86 (x64 does > not have a leading underscore), but the DLL had the symbol exported exactly > as was specified in the .def file. The resulting executable ran. I did not > try to > use LoadLibrary on the DLL. Yes, but that is an ABI change, on what is supposed to be a standardized interface. They can't just break all existing callers who expect the calling convention to be stdcall. I think the only way is to have separate def files for x86 and everything else. Does GetProcAddress not deal with stdcall-decorated exports transparently on x86? If not, you could define aliased symbols in the def file. I don't remember the exact syntax off the top of my head, but it's something like Foo@12 Foo = Foo@12 You might also be interested in the linker options --add-stdcall-alias/--enable-stdcall-fixup, but I think those are just for symbols exported by annotating with dllexport (or --export-all-symbols), not for those explicitly exported from a def file. ___ 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] mmsystem: remove _WIN32 and WINVER checks
On 4/29/23 06:17, Biswapriyo Nath wrote: I was about to send my fix and lost the race :) I have attached my patch just for the record. It focuses on the cygwin errors only. Your patch looks good to me. Thank you. Done, pushed to master, and v11.x. v11.0.1 tagged. ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] [Patch] mmsystem: remove _WIN32 and WINVER checks
We don't really support WINVER 0x030a or 0x0400, so remove those checks.
Likewise, the _WIN32 check is redundant since we lack any import
libraries to support non A/W suffixed function calls.
This should fix Cygwin w32api, tested locally.
Attached patch OK? I plan to also backport this to v11.From f630e28a056372dd0679eed81b866688e6144f3f Mon Sep 17 00:00:00 2001
From: Jonathan Yong <10wa...@gmail.com>
Date: Sat, 29 Apr 2023 02:54:03 +
Subject: [PATCH] mmsystem: remove _WIN32 and WINVER checks
e8b3bf18df was breaking w32api for Cygwin, which use win32 APIs,
but don't define _WIN32.
Signed-off-by: Jonathan Yong <10wa...@gmail.com>
---
mingw-w64-headers/include/joystickapi.h | 47
mingw-w64-headers/include/mciapi.h | 181 --
mingw-w64-headers/include/mmeapi.h | 288 ---
mingw-w64-headers/include/mmiscapi.h | 47
mingw-w64-headers/include/mmiscapi2.h | 5 -
mingw-w64-headers/include/mmsyscom.h | 25 --
mingw-w64-headers/include/mmsystem.h | 4 -
mingw-w64-headers/include/playsoundapi.h | 13 -
8 files changed, 610 deletions(-)
diff --git a/mingw-w64-headers/include/joystickapi.h b/mingw-w64-headers/include/joystickapi.h
index 2ac1816d6..80a32aeed 100644
--- a/mingw-w64-headers/include/joystickapi.h
+++ b/mingw-w64-headers/include/joystickapi.h
@@ -106,8 +106,6 @@ extern "C" {
#define JOYCAPS_POV4DIR 0x0020
#define JOYCAPS_POVCTS 0x0040
-#ifdef _WIN32
-
typedef struct tagJOYCAPSA {
WORD wMid;
WORD wPid;
@@ -121,7 +119,6 @@ typedef struct tagJOYCAPSA {
UINT wNumButtons;
UINT wPeriodMin;
UINT wPeriodMax;
-#if (WINVER >= 0x0400)
UINT wRmin;
UINT wRmax;
UINT wUmin;
@@ -134,7 +131,6 @@ typedef struct tagJOYCAPSA {
UINT wMaxButtons;
CHAR szRegKey[MAXPNAMELEN];
CHAR szOEMVxD[MAX_JOYSTICKOEMVXDNAME];
-#endif
} JOYCAPSA, *PJOYCAPSA, *NPJOYCAPSA, *LPJOYCAPSA;
typedef struct tagJOYCAPSW {
@@ -150,7 +146,6 @@ typedef struct tagJOYCAPSW {
UINT wNumButtons;
UINT wPeriodMin;
UINT wPeriodMax;
-#if (WINVER >= 0x0400)
UINT wRmin;
UINT wRmax;
UINT wUmin;
@@ -163,7 +158,6 @@ typedef struct tagJOYCAPSW {
UINT wMaxButtons;
WCHAR szRegKey[MAXPNAMELEN];
WCHAR szOEMVxD[MAX_JOYSTICKOEMVXDNAME];
-#endif
} JOYCAPSW, *PJOYCAPSW, *NPJOYCAPSW, *LPJOYCAPSW;
__MINGW_TYPEDEF_AW(JOYCAPS)
@@ -236,37 +230,6 @@ __MINGW_TYPEDEF_AW(PJOYCAPS2)
__MINGW_TYPEDEF_AW(NPJOYCAPS2)
__MINGW_TYPEDEF_AW(LPJOYCAPS2)
-#else
-typedef struct joycaps_tag {
- WORD wMid;
- WORD wPid;
- char szPname[MAXPNAMELEN];
- UINT wXmin;
- UINT wXmax;
- UINT wYmin;
- UINT wYmax;
- UINT wZmin;
- UINT wZmax;
- UINT wNumButtons;
- UINT wPeriodMin;
- UINT wPeriodMax;
-#if (WINVER >= 0x0400)
- UINT wRmin;
- UINT wRmax;
- UINT wUmin;
- UINT wUmax;
- UINT wVmin;
- UINT wVmax;
- UINT wCaps;
- UINT wMaxAxes;
- UINT wNumAxes;
- UINT wMaxButtons;
- char szRegKey[MAXPNAMELEN];
- char szOEMVxD[MAX_JOYSTICKOEMVXDNAME];
-#endif
-} JOYCAPS, *PJOYCAPS, *NPJOYCAPS, *LPJOYCAPS;
-#endif
-
typedef struct joyinfo_tag {
UINT wXpos;
UINT wYpos;
@@ -274,7 +237,6 @@ typedef struct joyinfo_tag {
UINT wButtons;
} JOYINFO, *PJOYINFO, *NPJOYINFO, *LPJOYINFO;
-#if (WINVER >= 0x0400)
typedef struct joyinfoex_tag {
DWORD dwSize;
DWORD dwFlags;
@@ -290,21 +252,14 @@ typedef struct joyinfoex_tag {
DWORD dwReserved1;
DWORD dwReserved2;
} JOYINFOEX, *PJOYINFOEX, *NPJOYINFOEX, *LPJOYINFOEX;
-#endif
-#if (WINVER >= 0x0400)
WINMMAPI MMRESULT WINAPI joyGetPosEx(UINT uJoyID, LPJOYINFOEX pji);
-#endif /* WINVER >= 0x0400 */
WINMMAPI UINT WINAPI joyGetNumDevs(void);
-#ifdef _WIN32
WINMMAPI MMRESULT WINAPI joyGetDevCapsA(UINT_PTR uJoyID, LPJOYCAPSA pjc, UINT cbjc);
WINMMAPI MMRESULT WINAPI joyGetDevCapsW(UINT_PTR uJoyID, LPJOYCAPSW pjc, UINT cbjc);
#define joyGetDevCaps __MINGW_NAME_AW(joyGetDevCaps)
-#else
-MMRESULT WINAPI joyGetDevCaps(UINT uJoyID, LPJOYCAPS pjc, UINT cbjc);
-#endif
WINMMAPI MMRESULT WINAPI joyGetPos(UINT uJoyID, LPJOYINFO pji);
WINMMAPI MMRESULT WINAPI joyGetThreshold(UINT uJoyID, LPUINT puThreshold);
@@ -312,9 +267,7 @@ WINMMAPI MMRESULT WINAPI joyReleaseCapture(UINT uJoyID);
WINMMAPI MMRESULT WINAPI joySetCapture(HWND hwnd, UINT uJoyID, UINT uPeriod, WINBOOL fChanged);
WINMMAPI MMRESULT WINAPI joySetThreshold(UINT uJoyID, UINT uThreshold);
-#if (WINVER >= 0x0400)
WINMMAPI MMRESULT WINAPI joyConfigChanged(DWORD dwFlags);
-#endif
#endif /* ifndef MMNOJOY */
diff --git a/mingw-w64-headers/include/mciapi.h b/mingw-w64-headers/include/mciapi.h
index ea9c7d6b7..0d2e3a26c 100644
--- a/mingw-w64-headers/include/mciapi.h
+++ b/mingw-w64-headers/include/mciapi.h
@@ -30,7 +30,6 @@ typedef UINT MCIDEVICEID;
typedef UINT (CALLBACK *YIELDPROC)(MCIDEVICEID mciId, DWORD dwYieldData);
-#ifdef _WIN32
WINMMAPI MCIERROR WINAPI mciSendCommandA(MCIDEVICEID mciId, UINT uMsg, DWORD_PTR dwParam1, DWORD_PTR dwParam2);
WINMMAPI MCIERR
Re: [Mingw-w64-public] Announcing v11.0.0
On 4/28/23 12:20, Jonathan Yong wrote: v11.0.0 is now released! Notable changes: * New libdloadhelper.a, like libdelayimp.a but using Windows 8 and later APIs. * Fix race condition when building lib32 and lib64 in parallel on Windows. * *recalloc now only available from msvcr90 and later, UCRT. * Redirect access() to __mingw_access() on UCRT wrt to X_OK problems. * New Hyper-V APIs. * SEH based setjmp on ARM if supported by compiler. * --enable-cfguard to enable Control Flow Guard in CRT, requires compiler support, clang only at this time. * Implement some of the stack protector functions/variables so -lssp is now optional when _FORTIFY_SOURCE or -fstack-protector-strong is used. * _FORTIFY_SOURCE=3 support added if __builtin_dynamic_object_size is supported by the compiler (gcc 12 or later). * genstubdll removed. * uchar_c16rtomb, uchar_c32rtomb, uchar_mbrtoc16 and uchar_mbrtoc32 removed for MSVCR*, UCRT only for now. * Updates to DX12 headers and much more from Wine. * Many other new win32 APIs. And many other additions thanks to, but not limited to (in Alphabetical order): Alvin Wong Biswapriyo Nath Christian Franke Christoph Reiter Costas Argyris delthas Dmitry Karasik Jacek Caban Jeremy Drake L. E. Segovia LIU Hao Luca Bacci Mark Harmstone Markus Mützel Martin Storsjö Mateusz Wajchęprzełóż Matthew Lugg Mike Gelfand Oleg Oshmyan Oleg Tolmatcev Ozkan Sezer Pali Rohár Raf Lopez Sergei Trofimovich Steve Lhomme TheShermanTanker Yannis Juglaret Yonggang Luo 李通洲 And here are the downloads: https://sourceforge.net/projects/mingw-w64/files/mingw-w64/mingw-w64-release/mingw-w64-v11.0.0.tar.bz2 https://sourceforge.net/projects/mingw-w64/files/mingw-w64/mingw-w64-release/mingw-w64-v11.0.0.tar.bz2.asc https://sourceforge.net/projects/mingw-w64/files/mingw-w64/mingw-w64-release/mingw-w64-v11.0.0.tar.bz2.sig https://sourceforge.net/projects/mingw-w64/files/mingw-w64/mingw-w64-release/mingw-w64-v11.0.0.zip https://sourceforge.net/projects/mingw-w64/files/mingw-w64/mingw-w64-release/mingw-w64-v11.0.0.zip.asc https://sourceforge.net/projects/mingw-w64/files/mingw-w64/mingw-w64-release/mingw-w64-v11.0.0.zip.sig Corrected the tar.bz2 link. 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
Re: [Mingw-w64-public] [PATCH 1/2] headers: Hide UTF-16 and UTF-32 functions from libmsvcrt
On 4/27/23 14:49, LIU Hao wrote: Basing on some discussion on IRC, I have spit this into two patches. The actual removal of these functions will be postponed after this release. Looks like there was a miscommunication, when I said to hide it from UCRT, I was agreeing with you. I prefer removing it as well if there is no correct implementation rather than lull further users from assuming it is working (or link tests passing since the symbol is present). The earlier version of the patch looks good to me, no need to split it, I prefer the next release also include the removal. ___ 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] crt: Remove conversion functions between UTF-{16, 32} characters from MSVCRT
On 4/22/23 14:46, LIU Hao wrote: 在 2023-03-30 16:38, LIU Hao 写道: Ping on this patch. A blank line got deleted by accident. I can fix that locally. Removal of stuff could be bad, but given that `mbstoc16()` has never been working, it might not be a big loss. Ping again? It has been almost a month about this patch. Sorry for the delay. I agree that having those functions implemented like that was a mistake. Now that we have them, I'm a bit afraid of breaking existing applications. I guess we don't know if anything is using those functions in non-UCRT environment. Still, I'm fine with the patch patch. If we find out that it breaks things, then we may consider having something in msvcrt importlibs later. That said, it feels risky and I heard some talks about doing a release soon. I don't know what's the current status, but if we're indeed releasing soon, it may make sense to delay committing it after that. Thanks, 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] clang shows compiler error with windows.ui.composition.h
On 4/26/23 22:30, Biswapriyo Nath wrote: The compiler error can be solved if DirectXAlphaMode is replaced with ABI::Windows::Graphics::DirectX::DirectXAlphaMode. I am not sure if this is an issue with widl generated header or an issue with clang and C++ standards. How can I troubleshoot this issue I looks like a widl bug, it should emit the type with full namespace prefix in this case. 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] crt: Remove conversion functions between UTF-{16, 32} characters from MSVCRT
Since there had been no other responses, I will add my opinion here: I am fine with removing these functions for msvcrt, only if mingw-w64 will never reimplement these functions in the future (i.e. will reject patches that add them). It seems very tricky to implement them correctly with msvcrt's definition of mbstate_t, anyway. On 22/4/2023 20:46, LIU Hao wrote: 在 2023-03-30 16:38, LIU Hao 写道: Ping on this patch. A blank line got deleted by accident. I can fix that locally. Removal of stuff could be bad, but given that `mbstoc16()` has never been working, it might not be a big loss. Ping again? It has been almost a month about this patch. ___ 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] headers: Import textstor.idl from wine
Pushed, thanks. 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] Migration from SF and port from Autotools
On 3/31/23 18:24, NightStrike wrote:
On Thu, Mar 30, 2023, 06:45 Jacek Caban via Mingw-w64-public
wrote:
On 3/20/23 16:44, مهدي شينون wrote:
> Hi everyone,
>
>
> Could you please consider migrating your project to another host
other
> than sourcefoge where people could file bugs, propose changes and
> discuss things (like GitHub ot GitLab).
>
> Using mailing-list for that is a way that's not suitable for young
> generation (including me).
>
> Many people try to report bugs or propose changes but ended up
ignored
> because of this insist on using this outdated technology!
We had similar talks in Wine for years and we finally decided
decided to
migrate to Gitlab last year. I think it was a good choice. We had it
running parallel to ML as an experiment first, here is the summary:
https://www.winehq.org/pipermail/wine-devel/2022-June/220008.html
I think most of it would apply to mingw-w64 as well. I'd like to
especially point CI: Gitlab makes it easy to set up CI and mingw-w64
could really use one. It's esp. nice for reviewers: by the time
you look
at the patch, you already know that it doesn't break the build.
The use of a hosted solution vs making lists for patches is orthogonal
to not using SF. We could use any of the many services SF offers, and
I pushed this hard over the years, but people like mailing list
patches. Part of it is old habits, part of it is accessibility. Patch
commenting on a website with markdown is neat and useful, but not very
accessible.
It's not website nor markdown that I care about (in fact, UI is not
really Gitlab's strong side). Better git utilization is nice to have. It
also makes CI easy to automate. Ideally CI would catch problems very
early, with no need to bother reviewers.
As for CI, remember that to have effective CI for us requires building
the whole toolchain. We used to do this daily with a buildbot service
set up by Mook and me, served by ReactOS, and run on donated hardware.
Mook left, react stopped giving us the server, and donors stopped
donating.
I'm working with MJW to get a builder running on the SW BB. That
should take care of this requirement, but mind you that native builds
can take days to finish.
It's sad that native builds take days to finish... Is there any hope
that it will improve? Is it a matter of Cygwin/msys being slow? If yes,
can it be optimized? If not...
Anyway, for pre-commit CI, we don't need a full toolchain bootstrap.
Rebuilding mingw-w64 parts using precompiled toolchains alone would be
nice. If we'd want to catch more problems, we could use that to also
build things like libgcc, libstc++, compiler-rt, libc++ and maybe some
more light but interesting external projects. Ideally using both GCC and
LLVM precompiled toolchains.
Wine uses self-hosted Gitlab instance, which solves the problem of
dependence on third party host. Having its own self-hosted
instance just
for mingw-w64 would probably be too much overhead for mingw-w64
project,
so if we decided to migrate, we'd need to pick one of externally
hosted
solutions.
BTW, SF mailing lists are especially not friendly for patches with
its
automatic footer messing inline patches and some attachments being
silently dropped, depending on their extensions.
That's configurable. If there's a mime type that needs adding, I can
add it.
How about allowing all MIME types? And for inline patches, can you
disable all mail body modifications?
As I pointed out previously, the use of auto tools by mingw-w64
doesn't stop anyone from using whatever they want in their own
project. If you're building mingw-w64, you're building gcc anyway, so
what difference does it make? You need a GNU environment (that's the G
in our name after all!), so running a configure script isn't really an
additional requirement. Whereas cmake would absolutely be a new
requirement.
LLVM is well supported by mingw-w64 for years now (and doesn't take days
to build). Cygwin/msys also don't fall into minimalist category, which
takes 3 of name letters (whatever that matters).
Jacek
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] SDKDDKVer.h default target version
I was recently dealing with a project that seems to have been creatd from a Visual Studio project template. It includes a "targetver.h" file with the following comments: // Including SDKDDKVer.h defines the highest available Windows platform. // If you wish to build your application for a previous Windows platform, include WinSDKVer.h and // set the _WIN32_WINNT macro to the platform you wish to support before including SDKDDKVer.h. However, in mingw-w64, including SDKDDKVer.h doesn't result in the highest available Windows platform, or even the default as specified to mingw-w64-headers' configure script. It seems to hardcode a default of "WS03" aka 0x0502. ___ 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] genpeimg: fix build error with clang v16
On 4/2/23 15:40, Christoph Reiter wrote:
Building genpeimg with clang v16 fails like:
error: implicit truncation from 'int' to a one-bit wide bit-field changes value
from 1 to -1 [-Werror,-Wsingle-bit-bitfield-constant-conversion]
pe->is_64bit = 1;
is_64bit is always ever comapred against 0 in our case, so the value change
doesn't matter, but let's just make it unsigned to fix the error and avoid
any future confusion.
The same is theoretically true for is_bigendian, but that currently
never set to 1 in any place. Make it unsigned as well while at it.
---
mingw-w64-tools/genpeimg/src/img.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/mingw-w64-tools/genpeimg/src/img.h
b/mingw-w64-tools/genpeimg/src/img.h
index 6e969a175..dd47a0f4b 100644
--- a/mingw-w64-tools/genpeimg/src/img.h
+++ b/mingw-w64-tools/genpeimg/src/img.h
@@ -67,8 +67,8 @@ typedef struct pe_image {
size_t optional_hdr_pos;
size_t section_list;
size_t section_list_sz; /* Each section entry has 40 bytes size. */
- int is_64bit : 1;
- int is_bigendian : 1;
+ unsigned int is_64bit : 1;
+ unsigned int is_bigendian : 1;
} pe_image;
pe_image *peimg_create (file_image *pimg);
Thanks, pushed to master branch.
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] GCC bugs with explicit template instantiation and dllexport targeting MinGW
Hi everyone, On 03/04/2023 07:04, LIU Hao wrote: > 在 2023/4/3 16:55, Vittorio Romeo 写道: >> Hello everyone, >> Hope you are doing well. >> >> I've encountered and reported a bug related to explicit template >> instantiations and dllexport using the latest version of GCC on >> MinGW/MSYS2: >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109380 > > I don't think it's a bug. There are two issues in your testcase, one is > that > > extern template struct __declspec(dllexport) S; > > is a declaration, and nothing can be exported from a declaration (you > export the definition instead). I believe this may be correct as per the standard, https://developercommunity.visualstudio.com/t/c11-extern-templates-doesnt-work-for-class-templat/157868#T-N355261 but not according to MinGW's own semantics: https://reviews.llvm.org/D61118 I recall we had to work around it in Krita to avoid a possible runtime symbol clash/crash: https://invent.kde.org/graphics/krita/-/commit/0ca27275ee9c8e7a4a2223cc4e66d12e95517edc > > The other is that `g()` is an implicit inline function. An inline > function can only be exported when it is emitted as a non-inline copy, > for example, when optimization is not enabled, or when its address is > taken, or when it is virtual and the class has a non-pure non-inline > virtual function (a.k.a. the key function) which instantiates its vtable. > > > > > > ___ > Mingw-w64-public mailing list > Mingw-w64-public@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public Best regards, amyspark -- amyspark https://www.amyspark.me ___ 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 2/2] crt: Add mi import library
(apologies for not including any quoted context, my mail client was not cooperating with trying to quote an attachment) Does the lib32/mi.def differ from the lib-common/mi.def? If not, couldn't the lib32 variant also be omitted? ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] [PATCH] headers: crt: Add declarations for _aligned_msize
Signed-off-by: Alvin Wong
---
> I think these declarations require checks for `__MSVCRT_VERSION__ >= 0x900`.
They already have the checks. Resending with more context lines.
mingw-w64-headers/crt/crtdbg.h | 1 +
mingw-w64-headers/crt/malloc.h | 1 +
mingw-w64-headers/crt/stdlib.h | 1 +
3 files changed, 3 insertions(+)
diff --git a/mingw-w64-headers/crt/crtdbg.h b/mingw-w64-headers/crt/crtdbg.h
index c8b99c817..e24d5053b 100644
--- a/mingw-w64-headers/crt/crtdbg.h
+++ b/mingw-w64-headers/crt/crtdbg.h
@@ -154,10 +154,11 @@ extern "C" {
#if __MSVCRT_VERSION__ >= 0x900
#define _recalloc_dbg(p,c,s,t,f,l) _recalloc(p,c,s)
#define _aligned_recalloc_dbg(p,c,s,a,f,l) _aligned_realloc(p,c,s,a)
#define _aligned_offset_recalloc_dbg(p,c,s,a,o,f,l)
_aligned_offset_recalloc(p,c,s,a,o)
+#define _aligned_msize_dbg(p,a,o) _aligned_msize(p,a,o)
#endif
#define _malloca_dbg(s,t,f,l) _malloca(s)
#define _freea_dbg(p,t) _freea(p)
diff --git a/mingw-w64-headers/crt/malloc.h b/mingw-w64-headers/crt/malloc.h
index c2003a19a..78599db94 100644
--- a/mingw-w64-headers/crt/malloc.h
+++ b/mingw-w64-headers/crt/malloc.h
@@ -67,10 +67,11 @@ extern "C" {
_CRTIMP void *__cdecl _aligned_offset_realloc(void *_Memory,size_t
_Size,size_t _Alignment,size_t _Offset);
# if __MSVCRT_VERSION__ >= 0x900
_CRTIMP void *__cdecl _recalloc(void *_Memory,size_t _Count,size_t _Size);
_CRTIMP void *__cdecl _aligned_recalloc(void *_Memory,size_t _Count,size_t
_Size,size_t _Alignment);
_CRTIMP void *__cdecl _aligned_offset_recalloc(void *_Memory,size_t
_Count,size_t _Size,size_t _Alignment,size_t _Offset);
+ _CRTIMP size_t __cdecl _aligned_msize(void *_Memory,size_t _Alignment,size_t
_Offset);
# endif
#endif
/* Users should really use MS provided versions */
void * __mingw_aligned_malloc (size_t _Size, size_t _Alignment);
diff --git a/mingw-w64-headers/crt/stdlib.h b/mingw-w64-headers/crt/stdlib.h
index 63aea7bfe..8e2649491 100644
--- a/mingw-w64-headers/crt/stdlib.h
+++ b/mingw-w64-headers/crt/stdlib.h
@@ -544,10 +544,11 @@ float __cdecl __MINGW_NOTHROW strtof(const char *
__restrict__ _Str,char ** __re
_CRTIMP void *__cdecl _aligned_offset_realloc(void *_Memory,size_t
_Size,size_t _Alignment,size_t _Offset);
# if __MSVCRT_VERSION__ >= 0x900
_CRTIMP void *__cdecl _recalloc(void *_Memory,size_t _Count,size_t _Size);
_CRTIMP void *__cdecl _aligned_recalloc(void *_Memory,size_t _Count,size_t
_Size,size_t _Alignment);
_CRTIMP void *__cdecl _aligned_offset_recalloc(void *_Memory,size_t
_Count,size_t _Size,size_t _Alignment,size_t _Offset);
+ _CRTIMP size_t __cdecl _aligned_msize(void *_Memory,size_t _Alignment,size_t
_Offset);
# endif
#endif
#ifndef _WSTDLIB_DEFINED
#define _WSTDLIB_DEFINED
--
2.40.0
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] [PATCH] headers: crt: Add declarations for _aligned_msize
Signed-off-by: Alvin Wong
---
mingw-w64-headers/crt/crtdbg.h | 1 +
mingw-w64-headers/crt/malloc.h | 1 +
mingw-w64-headers/crt/stdlib.h | 1 +
3 files changed, 3 insertions(+)
diff --git a/mingw-w64-headers/crt/crtdbg.h b/mingw-w64-headers/crt/crtdbg.h
index c8b99c817..e24d5053b 100644
--- a/mingw-w64-headers/crt/crtdbg.h
+++ b/mingw-w64-headers/crt/crtdbg.h
@@ -156,6 +156,7 @@ extern "C" {
#define _recalloc_dbg(p,c,s,t,f,l) _recalloc(p,c,s)
#define _aligned_recalloc_dbg(p,c,s,a,f,l) _aligned_realloc(p,c,s,a)
#define _aligned_offset_recalloc_dbg(p,c,s,a,o,f,l)
_aligned_offset_recalloc(p,c,s,a,o)
+#define _aligned_msize_dbg(p,a,o) _aligned_msize(p,a,o)
#endif
#define _malloca_dbg(s,t,f,l) _malloca(s)
diff --git a/mingw-w64-headers/crt/malloc.h b/mingw-w64-headers/crt/malloc.h
index c2003a19a..78599db94 100644
--- a/mingw-w64-headers/crt/malloc.h
+++ b/mingw-w64-headers/crt/malloc.h
@@ -69,6 +69,7 @@ extern "C" {
_CRTIMP void *__cdecl _recalloc(void *_Memory,size_t _Count,size_t _Size);
_CRTIMP void *__cdecl _aligned_recalloc(void *_Memory,size_t _Count,size_t
_Size,size_t _Alignment);
_CRTIMP void *__cdecl _aligned_offset_recalloc(void *_Memory,size_t
_Count,size_t _Size,size_t _Alignment,size_t _Offset);
+ _CRTIMP size_t __cdecl _aligned_msize(void *_Memory,size_t _Alignment,size_t
_Offset);
# endif
#endif
diff --git a/mingw-w64-headers/crt/stdlib.h b/mingw-w64-headers/crt/stdlib.h
index 63aea7bfe..8e2649491 100644
--- a/mingw-w64-headers/crt/stdlib.h
+++ b/mingw-w64-headers/crt/stdlib.h
@@ -546,6 +546,7 @@ float __cdecl __MINGW_NOTHROW strtof(const char *
__restrict__ _Str,char ** __re
_CRTIMP void *__cdecl _recalloc(void *_Memory,size_t _Count,size_t _Size);
_CRTIMP void *__cdecl _aligned_recalloc(void *_Memory,size_t _Count,size_t
_Size,size_t _Alignment);
_CRTIMP void *__cdecl _aligned_offset_recalloc(void *_Memory,size_t
_Count,size_t _Size,size_t _Alignment,size_t _Offset);
+ _CRTIMP size_t __cdecl _aligned_msize(void *_Memory,size_t _Alignment,size_t
_Offset);
# endif
#endif
--
2.40.0
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Migration from SF and port from Autotools
On 3/20/23 16:44, مهدي شينون wrote: Hi everyone, Could you please consider migrating your project to another host other than sourcefoge where people could file bugs, propose changes and discuss things (like GitHub ot GitLab). Using mailing-list for that is a way that's not suitable for young generation (including me). Many people try to report bugs or propose changes but ended up ignored because of this insist on using this outdated technology! We had similar talks in Wine for years and we finally decided decided to migrate to Gitlab last year. I think it was a good choice. We had it running parallel to ML as an experiment first, here is the summary: https://www.winehq.org/pipermail/wine-devel/2022-June/220008.html I think most of it would apply to mingw-w64 as well. I'd like to especially point CI: Gitlab makes it easy to set up CI and mingw-w64 could really use one. It's esp. nice for reviewers: by the time you look at the patch, you already know that it doesn't break the build. Wine uses self-hosted Gitlab instance, which solves the problem of dependence on third party host. Having its own self-hosted instance just for mingw-w64 would probably be too much overhead for mingw-w64 project, so if we decided to migrate, we'd need to pick one of externally hosted solutions. BTW, SF mailing lists are especially not friendly for patches with its automatic footer messing inline patches and some attachments being silently dropped, depending on their extensions. That combined with other controversies (see https://en.wikipedia.org/wiki/SourceForge Controversies paragraph) makes me think that SF is not an optimal host for the project. Could you also port the project to a better buildsystem, like cmake or meson. Autotools is not a buildsystem to choose to develop for Windows. The honest true is that autotools work well for a number of people, mostly those who cross compile mingw-w64. This does not seem to be true when building natively on Windows. I don't have experience with building on Windows (so I'm one of those for whom it works well), but I think that if there is anything we can do to improve native experience, we should seriously consider it. Windows support should obviously be important for the project. I'd be open to discuss changing build system, but the bottom line is that it's a lot of work, it's not something we can do easily. Thanks, 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] crt: Reimplement `dirname()` and `basename()`
Hi,
Overall I think the implementation looks fine. The test cases are
missing some of the more exotic DOS device paths[1], for example
`\\.\Volume{b75e2c83----602f}\` but to be frank I
don't know what should be the expected outputs for it. Should we simply
declare that DOS device paths may not work as expected?
[1]:
https://learn.microsoft.com/en-us/dotnet/standard/io/file-path-formats#dos-device-paths
Manual fuzzing with asan and ubsan revealed an issue: The line
`info.prefix_end[1] = 0;` (line 213) can result in a buffer overrun.
This happens with inputs in the form of an UNC host only, e.g. `\\host`,
which is also missing from the test cases.
I would think the fix is as simple as changing line 211 to
`if(info.prefix_end < info.path_end - 1) {`, but this revealed another
issue because `info.path_end` contained an uninitialized value -- an
early return in `do_get_path_info` (line 127) missed setting
`info->path_end = pos;`. After applying these fixes there seems to be no
other sanitizer issues. I have attached my test which I built with
`clang -fsanitize=address,undefined`.
Cheers,
Alvin
On 26/3/2023 17:09, LIU Hao wrote:
As discussed on IRC just now, paths are not affected by the global
locale. According to Microsoft documentation about `fopen()` [1],
paths are interpreted with `CP_ACP` if `AreFileApisANSI()` returns
true, and `CP_OEMCP` otherwise. We had better follow that convention.
[1]
https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/fopen-wfopen?view=msvc-170
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public#define TEST_CODEPAGE 950
// #define TEST_CODEPAGE CP_UTF8
#define _CRT_RAND_S
// -
/**
* This file has no copyright assigned and is placed in the Public Domain.
* This file is part of the mingw-w64 runtime package.
* No warranty is given; refer to the file DISCLAIMER.PD within this package.
*/
#ifndef WIN32_LEAN_AND_MEAN
#define WIN32_LEAN_AND_MEAN
#endif
#include
#include
#include
/* A 'directory separator' is a byte that equals 0x2F ('solidus' or more
* commonly 'forward slash') or 0x5C ('reverse solidus' or more commonly
* 'backward slash'). The byte 0x5C may look different from a backward slash
* in some locales; for example, it looks the same as a Yen sign in Japanese
* locales and a Won sign in Korean locales. Despite its appearance, it still
* functions as a directory separator.
*
* A 'path' comprises an optional DOS drive letter with a colon, and then an
* arbitrary number of possibily empty components, separated by non-empty
* sequences of directory separators (in other words, consecutive directory
* separators are treated as a single one). A path that comprises an empty
* component denotes the current working directory.
*
* An 'absolute path' comprises at least two components, the first of which
* is empty.
*
* A 'relative path' is a path that is not an absolute path. In other words,
* it either comprises an empty component, or begins with a non-empty
* component.
*
* POSIX doesn't have a concept about DOS drives. A path that does not have a
* drive letter starts from the same drive as the current working directory.
*
* For example:
* (Examples without drive letters match POSIX.)
*
* Argument dirname() returnsbasename() returns
* ---
* `` or NULL `.` `.`
* `usr``.` `usr`
* `usr\` `.` `usr`
* `\` `\` `\`
* `\usr` `\` `usr`
* `\usr\lib` `\usr` `lib`
* `\home\\dwc\\test` `\home\\dwc` `test`
* `\\host\usr` `\\host\.` `usr`
* `\\host\usr\lib` `\\host\usr` `lib`
* `\\host\\usr``\\host\\` `usr`
* `\\host\\usr\lib``\\host\\usr``lib`
* `C:` `C:.``.`
* `C:usr` `C:.``usr`
* `C:usr\` `C:.``usr`
* `C:\``C:\``\`
* `C:\\` `C:\``\`
* `C:\\\` `C:\``\`
* `C:\usr` `C:\``usr`
* `C:\usr\lib` `C:\usr` `lib`
* `C:\\usr\\lib\\` `C:\\usr``lib`
* `C:\home\\dwc\\test` `C:\home\\dwc` `test`
*/
struct path_info
{
/* This points to end of the UNC prefix and drive letter, if any. */
char* prefix_end;
/* These point to the dir
Re: [Mingw-w64-public] [PATCH] rewrite the dirname.c and basename.c without wide character processing
On 25/3/2023 17:28, LIU Hao wrote: 在 2023-03-25 12:35, Alvin Wong 写道: Can we just avoid converting to wide char at all and operate only in MBCS? IsDBCSLeadByte should be enough to allow these functions to skip any false matches on the second byte of double-byte chars. And it does not matter that IsDBCSLeadByte doesn't work with UTF-8, because the UTF-8 encoding already ensures that there will be no false matches with 7-bit ASCII chars (all bytes forming multi-byte chars have the MSB set, unlike some DBCS). While this argument is almost correct on its own (except that `IsDBCSLeadByteEx()` is preferred to `IsDBCSLeadByte()`), we should not declare these functions as working with UTF-8. As explained in a previous message, the Yen symbol (`¥`, two bytes in UTF-8: C2 A5) is a path separator in Japanese locales, and the Won symbol (`₩`, three bytes in UTF-8: E2 82 A9) is also a path separator in Korean locales; This claim needs to be verified. The native path separator on Windows should be only U+005C (with APIs also accepting U+002F). While both U+005C and U+00A5 translates to 0x5C in CP932, Windows uses Unicode to handle files and NTFS uses Unicode file names. If you give Windows the path `L"C:\134new\245folder"`, I can't really imagine it referring to `C:\new\folder` rather than `C:\new¥folder` when system code page is in Japanese. Of course, if you first translate the path to CP932, or if you are using a program that does not use the Unicode Windows APIs, then you will not be able to refer to `new¥folder`. I think the following things need to be checked: 1. From Windows Explorer, can you create a file or folder containing U+00A5 in its name on Japanese Windows? (Don't try from cmd.exe.) 2. If you create a file or folder containing U+00A5 on an NTFS volume from another non-Japanese system, can you access it from Windows Explorer on Japanese Windows? 3. Create the path `C:\new\folder` and try to access it using the Unicode Windows API with the path `L"C:\134new\245folder"`. 4. Create the path `C:\new¥folder` (with U+00A5) and try the same. 5. Check the above two points, but with embedded manifest setting the active code page to UTF-8, and using the "-A" APIs with a UTF-8 string instead. 6. Check whether MultiByteToWideChar converts 0x5C from CP932 to U+005C or U+00A5. Remember that U+005C and U+00A5 can look exactly the same in the Japanese font on Windows, so you should verify you have the correct code point when testing. those are not something we can handle, because we can't know the encoding of the argument string. We can check the value of `GetACP()`, although I am not convinced we need to. ___ 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] rewrite the dirname.c and basename.c without wide character processing
Can we just avoid converting to wide char at all and operate only in MBCS? IsDBCSLeadByte should be enough to allow these functions to skip any false matches on the second byte of double-byte chars. And it does not matter that IsDBCSLeadByte doesn't work with UTF-8, because the UTF-8 encoding already ensures that there will be no false matches with 7-bit ASCII chars (all bytes forming multi-byte chars have the MSB set, unlike some DBCS). On 23/3/2023 13:29, LIU Hao wrote: 在 2023-03-22 13:40, 傅继晗 写道: Hello: There is no need to convert multi-byte characters to wide-byte characters and then convert from wide-byte to multi-byte, just deal with multi-byte directly as __xpg_basename in gnu as this： glibc/xpg_basename.c at master · lattera/glibc (github.com) <https://github.com/lattera/glibc/blob/master/stdlib/xpg_basename.c> Converting multi-byte characters to wide-byte characters can lead to garbled code problems if the incoming filename encoding does not match the system default encoding returned by GetACP().And environment variables do not work there. I was also thinking about reimplementation of these functions, but there are things that we must take care of: 1. The conversion from multibyte character strings (MBCS) to wide character strings (WCS) is necessary, because non-leading bytes in some MBCS encodings may match the black slash `\` (U+005C). 2. Not only forward and backward slashes are path separators. The conventional Shift JIS encoding has the Yen symbol `¥` (U+00A5) take the place of the ASCII backslash, and a Yen symbol is displayed for the byte 0x5C if a Shift JIS locale is activated. This means that `mbstowc()` will convert the string "a¥b" (hex: 61 5C 62) to L"a¥b" (hex: 0061 00A5 0062) and we have to also accept `¥` as a path separator in Japanese locales. 3. Something similar to 2 happens about the Won symbol `₩` (U+20A9) in Korean locales, so we have to accept it, too. 4. Don't ever try to modify the global locale, due to thread safety. OK, it has been too much. How do we implement this correctly? First we need to make an assumption about the input, for example, let's assume it is a path in Shift JIS encoding. 1. Don't check wide characters for path separators! As explained above, not only slashes are path separators. Japanese and Korean are what I happen to know, but there could be a couple more. We notice that the byte 5C is always a path separator, no matter what it may map to, `\`, `¥` or `₩`. Hence, only the original MBCS should be scanned for path separators, which are `/` (U+002F) and `\` (U+005C), but nothing else. 2. It's necessary to convert it to a WCS first. Ideally the caller should have set the global locale... but are they aware of it? Maybe this should be done via `MultiByteToWideChar()`, like other functions. 3. So what is the conversion for? We can't make use of the output of such conversion, but it gives information about how many bytes that a character takes in the original MBCS, so we can know how many bytes to move forward (a multiple-byte character is never a path separator), and will not a mistake non-leading byte as a path separator. ___ 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] crt: Make CRT buildable with `-masm=intel`
On 3/23/23 07:03, Martin Storsjö wrote: On Wed, 22 Mar 2023, Jacek Caban wrote: On 3/22/23 15:21, LIU Hao wrote: 在 2023-03-22 21:07, Jacek Caban 写道: That's the motivation for this? I can see a point in supporting both syntaxes in headers (which may be included by users with various compiler options), but for crt, why isn't supporting a single syntax understood by all supported compilers enough? Yes that is the only motivation. Why? Because AT is unofficial, foreign, and awkward. 1. No Intel or AMD doc ever speaks this way. This is already enough for being thrown into the dustbin of history. 2. It was designed for PDP originally, and got widespread just because Plan 9 dogs couldn't stop barking. Oh please take a look at the Go assembler, and what they've done to ARM, brilliant. 3. And, we want `xmm0 = xmm1 - xmm2` and `vsubpd xmm0, xmm1, xmm2`, not the backward nonsense `vsubpd %xmm2, %xmm1, %xmm0`; same for `cmp`. 4. And we want `mov eax, [rsi + rbx * 8 + 12]`, not `movl 12(%rsi, %rbx, 8), %eax`. Intel syntax also copes better with other tools - Microsoft compilers, NASM, IDA, x64dbg, countless assembler and disassemblers - none of them produce or accept nonstandard AT syntax in any way. There have been enough talks about that [1]; I hope I would not have to repeat myself [2]. [1] https://outerproduct.net/2021-02-13_att-asm.html [2] https://gcc.gnu.org/pipermail/gcc/2022-November/240103.html I didn't really mean to ask which syntax is better, but what exactly are we trying to achieve. From GCC thread, my understanding is that you want to support toolchains that default to Intel syntax. How about the attached patch? You need to move the option down into (the weirdly named) CPPFLAGS32 and CPPFLAGS64; for arm/aarch64 targets, Clang warns and GCC errors if given the -masm=att parameter. Oh, right, thanks. I pushed with that changed. If we find more compatibility problems, we can also have configure check, but that doesn't seem needed at this point. Thanks, 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] crt: Make CRT buildable with `-masm=intel`
On 3/22/23 15:21, LIU Hao wrote: 在 2023-03-22 21:07, Jacek Caban 写道: That's the motivation for this? I can see a point in supporting both syntaxes in headers (which may be included by users with various compiler options), but for crt, why isn't supporting a single syntax understood by all supported compilers enough? Yes that is the only motivation. Why? Because AT is unofficial, foreign, and awkward. 1. No Intel or AMD doc ever speaks this way. This is already enough for being thrown into the dustbin of history. 2. It was designed for PDP originally, and got widespread just because Plan 9 dogs couldn't stop barking. Oh please take a look at the Go assembler, and what they've done to ARM, brilliant. 3. And, we want `xmm0 = xmm1 - xmm2` and `vsubpd xmm0, xmm1, xmm2`, not the backward nonsense `vsubpd %xmm2, %xmm1, %xmm0`; same for `cmp`. 4. And we want `mov eax, [rsi + rbx * 8 + 12]`, not `movl 12(%rsi, %rbx, 8), %eax`. Intel syntax also copes better with other tools - Microsoft compilers, NASM, IDA, x64dbg, countless assembler and disassemblers - none of them produce or accept nonstandard AT syntax in any way. There have been enough talks about that [1]; I hope I would not have to repeat myself [2]. [1] https://outerproduct.net/2021-02-13_att-asm.html [2] https://gcc.gnu.org/pipermail/gcc/2022-November/240103.html I didn't really mean to ask which syntax is better, but what exactly are we trying to achieve. From GCC thread, my understanding is that you want to support toolchains that default to Intel syntax. How about the attached patch? Thanks, Jacek diff --git a/mingw-w64-crt/Makefile.am b/mingw-w64-crt/Makefile.am index 933ff5532..3db2f307b 100644 --- a/mingw-w64-crt/Makefile.am +++ b/mingw-w64-crt/Makefile.am @@ -20,7 +20,7 @@ else endif AM_CPPFLAGS=$(sysincludes) -AM_CFLAGS=-pipe -std=gnu99 -D_CRTBLD -D_WIN32_WINNT=0x0f00 -D__MSVCRT_VERSION__=0x700 -D__USE_MINGW_ANSI_STDIO=0 @CFGUARD_CFLAGS@ @ADD_C_CXX_WARNING_FLAGS@ @ADD_C_ONLY_WARNING_FLAGS@ +AM_CFLAGS=-pipe -std=gnu99 -masm=att -D_CRTBLD -D_WIN32_WINNT=0x0f00 -D__MSVCRT_VERSION__=0x700 -D__USE_MINGW_ANSI_STDIO=0 @CFGUARD_CFLAGS@ @ADD_C_CXX_WARNING_FLAGS@ @ADD_C_ONLY_WARNING_FLAGS@ AM_CXXFLAGS=@ADD_C_CXX_WARNING_FLAGS@ @ADD_CXX_ONLY_WARNING_FLAGS@ CPPFLAGSARM32=-mfpu=vfpv3 CPPFLAGS32=-m32 ___ 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] crt: Make CRT buildable with `-masm=intel`
On 3/22/23 04:08, LIU Hao wrote:
This is the first attempt to allow the CRT to be built with
`-masm=intel`. This patch itself may look messy because it contains a
lot of inline changes. It should be examined with `git show
--color-words='\S'`.
I have only verified that the CRT actually builds with
{i686,x86_64}-w64-mingw32-gcc; not sure whether anything goes wrong.
Martin, would you please include this patch in your nightly tests?
`-masm=intel` requires the latest Clang, though. Older versions do not
accept Intel syntax in inline assembly (but they do output Intel syntax).
That's the motivation for this? I can see a point in supporting both
syntaxes in headers (which may be included by users with various
compiler options), but for crt, why isn't supporting a single syntax
understood by all supported compilers enough?
Thanks,
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 ]add UTF-8 support for dirname and basename
The thing is, the code point sequence you have here is not valid UTF-8
at all. If it is indeed doing the conversion from UTF-8 you will most
likely get incorrect result or crashes.
As you realized and reported in another reply that you were actually
testing with msvcrt. It is likely that msvcrt just ignored the
unsupported locale and was doing something unspecified.
On 20/3/2023 19:07, 傅继晗 wrote:
However,I use GBK as default code page in my windows , and I try to
test it with GBK encoding content .But this trick seems still
work.Here is the test case.
#include
extern char * __cdecl basename (char *path);
void xprint(const char *s)
{
while (*s)
printf("\\x%02x", (int)(unsigned char)(*s++));
}
int main(int argc, char **argv)
{
char input[]
={0x2f,0x73,0x64,0x63,0x61,0x72,0x64,0x2f,0xcc,0xec,0xcc,0xec,0xcf,0xf2,0xc9,0xcf,0x00};
// it is gbk encoding of "/sdcard/天天向上"
char *output;
printf("basename(\"");
xprint(input);
printf("\") = \"");
output = basename(input);
xprint(output);
printf("\"\n");
return 0;
}
Alvin Wong 于2023年3月20日周一 18:52写道：
Hi,
Thanks for sending the patches. However my comment on these
patches will be that, they only work when the process ANSI
codepage (ACP) is UTF-8, which requires either embedding a
manifest with activeCodePage set to UTF-8 or setting the system
ACP to UTF-8. If the process is using CP936 (GBK) for example, it
will still be broken similar to before.
Just my two cents: I would prefer to remove any code that changes
the locale then attempt to restore it (which is not thread-safe),
then replace `mbstowcs` and `wcstombs` with direct usage of
`MultiByteToWideChar` and `WideCharToMultiByte`, which can convert
from/to CP_ACP directly.
Best Regards,
Alvin
On 20/3/2023 18:36, 傅继晗 wrote:
ok，it has txt extension now
Alvin Wong 于2023年3月20日周一 18:10写道：
Hi, if you attached a patch in your mail, it has been
stripped by the
mailing list software. Please try renaming it to `.txt` and
resend.
On 20/3/2023 16:55, 傅继晗 wrote:
> Hello maintainers:
>
> According to microsoft page:setlocale, _wsetlocale |
Microsoft Learn
>
<https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/setlocale-wsetlocale?view=msvc-170>
>
> *Starting in Windows 10 version 1803 (10.0.17134.0), the
Universal C
> Runtime supports using a UTF-8 code page. The change means
that char
> strings passed to C runtime functions can expect strings in
the UTF-8
> encoding.*
>
> But the libmingwex.a in toolchain of Mingw-w64-public
doesn't support
> non-ascii file name,and cause some bugs in project,see :
> MinGW-w64 - for 32 and 64 bit Windows / Bugs / #227
basename() truncates
> filenames with variable-width encoding (sourceforge.net
<http://sourceforge.net>)
> <https://sourceforge.net/p/mingw-w64/bugs/227/>
> and AOSP adb pull push error
> Google Issue Tracker
<https://issuetracker.google.com/issues/143232373>
>
> so,the patches for dirname.c and basename.c is needed to
support utf-8
> encoding.
>
> Greetings
>
> fjh1997
>
> ___
> 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 ]add UTF-8 support for dirname and basename
Hi,
Thanks for sending the patches. However my comment on these patches will
be that, they only work when the process ANSI codepage (ACP) is UTF-8,
which requires either embedding a manifest with activeCodePage set to
UTF-8 or setting the system ACP to UTF-8. If the process is using CP936
(GBK) for example, it will still be broken similar to before.
Just my two cents: I would prefer to remove any code that changes the
locale then attempt to restore it (which is not thread-safe), then
replace `mbstowcs` and `wcstombs` with direct usage of
`MultiByteToWideChar` and `WideCharToMultiByte`, which can convert
from/to CP_ACP directly.
Best Regards,
Alvin
On 20/3/2023 18:36, 傅继晗 wrote:
ok，it has txt extension now
Alvin Wong 于2023年3月20日周一 18:10写道：
Hi, if you attached a patch in your mail, it has been stripped by the
mailing list software. Please try renaming it to `.txt` and resend.
On 20/3/2023 16:55, 傅继晗 wrote:
> Hello maintainers:
>
> According to microsoft page:setlocale, _wsetlocale | Microsoft Learn
>
<https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/setlocale-wsetlocale?view=msvc-170>
>
> *Starting in Windows 10 version 1803 (10.0.17134.0), the Universal C
> Runtime supports using a UTF-8 code page. The change means that char
> strings passed to C runtime functions can expect strings in the
UTF-8
> encoding.*
>
> But the libmingwex.a in toolchain of Mingw-w64-public doesn't
support
> non-ascii file name,and cause some bugs in project,see :
> MinGW-w64 - for 32 and 64 bit Windows / Bugs / #227 basename()
truncates
> filenames with variable-width encoding (sourceforge.net
<http://sourceforge.net>)
> <https://sourceforge.net/p/mingw-w64/bugs/227/>
> and AOSP adb pull push error
> Google Issue Tracker
<https://issuetracker.google.com/issues/143232373>
>
> so,the patches for dirname.c and basename.c is needed to support
utf-8
> encoding.
>
> Greetings
>
> fjh1997
>
> ___
> 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 ]add UTF-8 support for dirname and basename
Hi, if you attached a patch in your mail, it has been stripped by the mailing list software. Please try renaming it to `.txt` and resend. On 20/3/2023 16:55, 傅继晗 wrote: Hello maintainers: According to microsoft page:setlocale, _wsetlocale | Microsoft Learn <https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/setlocale-wsetlocale?view=msvc-170> *Starting in Windows 10 version 1803 (10.0.17134.0), the Universal C Runtime supports using a UTF-8 code page. The change means that char strings passed to C runtime functions can expect strings in the UTF-8 encoding.* But the libmingwex.a in toolchain of Mingw-w64-public doesn't support non-ascii file name,and cause some bugs in project,see : MinGW-w64 - for 32 and 64 bit Windows / Bugs / #227 basename() truncates filenames with variable-width encoding (sourceforge.net) <https://sourceforge.net/p/mingw-w64/bugs/227/> and AOSP adb pull push error Google Issue Tracker <https://issuetracker.google.com/issues/143232373> so,the patches for dirname.c and basename.c is needed to support utf-8 encoding. Greetings fjh1997 ___ 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] headers: explicitly define Reserved bits in DXVAHD_BLT_STATE, structures
On 3/17/23 15:39, Steve Lhomme wrote: On 2023-03-17 15:28, Biswapriyo Nath wrote: 1. You missed the Reserved member in DXVAHD_STREAM_STATE_INPUT_COLOR_SPACE_DATA. 2. There should be __C89_NAMELESS before the struct and union keywords. Indeed, good catch. Here is v2 of the patch. This doesn't build, __C89_NAMELESS* macros are not meant to be used in IDL files. widl takes care of adding them when generating headers. Thanks, 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] gdtoa: Sync to match the latest version at netlib.org
Hi, it seems the mailing list software stripped your attached patch. Please try resending it with a .txt file extension. (I suspect that Gmail doesn't send the .patch files with the MIME type `text/plain`.) On 7/1/2023 11:10, Jameson Nash wrote: I noticed that gdtoa upstream appeared to have some changes that were not reflected here, so I tried to copy them into mingw-w64 here. I had to partly guess at what the diff was between the old and current versions because upstream does not seem to provide version control, so this is a bit hard to illustrate. For future reference, this is the content from today: https://github.com/vtjnash/gdtoa/commit/a37a5e1354210f135003cc734cb097eee48e58b5, which is also included as a tgz in the commit here for future reference. I did not import any of the new features (new files) since those are not specified as part of C9x or POSIX, so they did not seem necessary. ___ 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] headers/intrin-impl: Expand `__movsd` to `movsl` in default AT syntax
On 2/27/23 09:36, LIU Hao wrote: 在 2023/2/24 23:45, LIU Hao 写道: From 00e46892b8e2407aa6ec47af4b5a793a170d5019 Mon Sep 17 00:00:00 2001 From: LIU Hao Date: Fri, 24 Feb 2023 23:38:52 +0800 Subject: [PATCH] headers/intrin-impl: Expand `__movsd` to `movsl` in default AT syntax This was originally reported on mailing list [1]. Because `movsd` will probably be dropped by GNU AS [2], `movsl` shall be used. Clang seems to accept both. [1]https://sourceforge.net/p/mingw-w64/mailman/message/37780661/ [2]https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=04784e33fabb45c4de7a901587f468d4bc169649 Signed-off-by: LIU Hao --- mingw-w64-headers/include/psdk_inc/intrin-impl.h | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) Ping? Makes sense to me, OK to commit. Thanks. ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] gcc shows warning with
For reference, the warning is from https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=04784e33fabb45c4de7a901587f468d4bc169649 (new in binutils 2.40). Clang's inline assembly can parse the grotesque at syntax and generate Intel syntax [1]; I am a bit curious how this is done. Pretty sure Compiler Explorer is just using the `-masm=intel` command line flag, which both Clang and GCC supports. On 24/2/2023 0:49, LIU Hao wrote: 在 2023-02-21 00:09, Biswapriyo Nath 写道: __INTRINSICS_USEINLINE -__buildmov(__movsd, unsigned __LONG32, "d") +__buildmov(__movsd, unsigned __LONG32, "l") #endif #define __INTRINSIC_DEFINED___movsd #endif /* __INTRINSIC_PROLOG */ I am not sure if this is valid fix. Feel free to apply the diff as maintainers like. A little explanation would be helpful also. This looks correct. Clang's inline assembly can parse the grotesque at syntax and generate Intel syntax [1]; I am a bit curious how this is done. Clang seems to accept both. [1] https://gcc.godbolt.org/z/6z11qTYa7 ___ 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] headers: Don't use __mingw_wcstod/wcstof on UCRT
On 1/20/23 13:49, Martin Storsjö wrote: The UCRT provided versions should be fully C99 compliant. This matches what was done for strtod/strtof for the initial configuration for UCRT in 265d0a5e3f087ed6bd68412cceed5e27e3ef62ae. Also clarify the endif comment, and make the condition in wchar.h consistent with the one in stdlib.h. Signed-off-by: Martin Storsjö --- mingw-w64-headers/crt/stdlib.h | 4 ++-- mingw-w64-headers/crt/wchar.h | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) Looks good to me. Thanks, 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] New Direct-Storage APIs in the MinGW-W64 toolchain
Hi, It looks like the DirectStorage SDK itself includes proprietary DLLs that will need to be redistributed together with the application. The license appears to be proprietary, which means it will not be usable at least from GPL-licensed applications. MinGW-w64 cannot supply these DLLs, at least not without a clean-room reimplementation, so it doesn't seem to make sense for MinGW-w64 to add the include headers and the import lib for this API for now. If the license is not a problem for you, you can probably download the NuGet package and extract the files from it. The headers may not work out of the box but I guess it shouldn't be too difficult to adapt them to work with MinGW-w64. Note: The above reflects my personal opinion only. Best Regards, Alvin On 17/1/2023 20:40, Rishabh Shukla wrote: Hi Team MinGW, Microsoft has introduced new set of APIs to support DirectStorage, that can be included through nuget/vcpkg; it includes, lib and dll- dstorage.lib dstorage.dll dstoragecore.dll headers- dstorage.h dstorageerr.h Please check the below mentioned link for more information, https://devblogs.microsoft.com/directx/directstorage-api-downloads/ Is it possible for you guys to add support for the above mentioned headers and libraries in MinGW packages? Please let me know your thoughts on this. Thanks you for all your work and support. Regards, Rishabh ___ 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
[Mingw-w64-public] [PATCH v2] headers: Add shcore.h
Signed-off-by: Alvin Wong
---
Removed trailing comma after last enum item.
mingw-w64-headers/include/shcore.h | 33 ++
1 file changed, 33 insertions(+)
create mode 100644 mingw-w64-headers/include/shcore.h
diff --git a/mingw-w64-headers/include/shcore.h
b/mingw-w64-headers/include/shcore.h
new file mode 100644
index 0..b51d5c488
--- /dev/null
+++ b/mingw-w64-headers/include/shcore.h
@@ -0,0 +1,33 @@
+/**
+ * This file has no copyright assigned and is placed in the Public Domain.
+ * This file is part of the mingw-w64 runtime package.
+ * No warranty is given; refer to the file DISCLAIMER.PD within this package.
+ */
+
+#ifndef _SHCORE_H_
+#define _SHCORE_H_
+
+#include
+
+#if NTDDI_VERSION >= NTDDI_WIN8
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+typedef enum {
+BSOS_DEFAULT = 0,
+BSOS_PREFERDESTINATIONSTREAM
+} BSOS_OPTIONS;
+
+STDAPI CreateRandomAccessStreamOnFile(PCWSTR filePath, DWORD accessMode,
REFIID riid, void **ppv);
+STDAPI CreateRandomAccessStreamOverStream(IStream *stream, BSOS_OPTIONS
options, REFIID riid, void **ppv);
+STDAPI CreateStreamOverRandomAccessStream(IUnknown *randomAccessStream, REFIID
riid, void **ppv);
+
+#ifdef __cplusplus
+}
+#endif
+
+#endif /* NTDDI_VERSION >= NTDDI_WIN8 */
+
+#endif
--
2.39.0
___
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] headers: Add shcore.h
On 26/12/2022 8:45, JonY via Mingw-w64-public wrote: On 12/25/22 14:53, Alvin Wong via Mingw-w64-public wrote: Signed-off-by: Alvin Wong --- Added according to https://learn.microsoft.com/en-us/windows/win32/api/shcore/. These functions are used for WinRT interop with IStream. mingw-w64-headers/include/shcore.h | 33 ++ 1 file changed, 33 insertions(+) create mode 100644 mingw-w64-headers/include/shcore.h +STDAPI CreateRandomAccessStreamOnFile(PCWSTR filePath, DWORD accessMode, REFIID riid, void **ppv); +STDAPI CreateRandomAccessStreamOverStream(IStream *stream, BSOS_OPTIONS options, REFIID riid, void **ppv); +STDAPI CreateStreamOverRandomAccessStream(IUnknown *randomAccessStream, REFIID riid, void **ppv); + Please include the dllimport attributes Should I use `DECLSPEC_IMPORT HRESULT WINAPI` instead of `STDAPI` then? and provide the library def file from gendef. That `shcore.def` already exists in mingw-w64. ___ 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] headers: Add shcore.h
On 12/25/22 14:53, Alvin Wong via Mingw-w64-public wrote: Signed-off-by: Alvin Wong --- Added according to https://learn.microsoft.com/en-us/windows/win32/api/shcore/. These functions are used for WinRT interop with IStream. mingw-w64-headers/include/shcore.h | 33 ++ 1 file changed, 33 insertions(+) create mode 100644 mingw-w64-headers/include/shcore.h +STDAPI CreateRandomAccessStreamOnFile(PCWSTR filePath, DWORD accessMode, REFIID riid, void **ppv); +STDAPI CreateRandomAccessStreamOverStream(IStream *stream, BSOS_OPTIONS options, REFIID riid, void **ppv); +STDAPI CreateStreamOverRandomAccessStream(IUnknown *randomAccessStream, REFIID riid, void **ppv); + Please include the dllimport attributes and provide the library def file from gendef. ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] [RFC PATCH] headers: Add robuffer.idl to generate robuffer.h
Signed-off-by: Alvin Wong
---
Implemented according to
https://learn.microsoft.com/en-us/windows/win32/api/robuffer/. This file
defines the Windows::Storage::Streams::IBufferByteAccess interface which
implementors of (ABI::)Windows::Storage::Streams::IBuffer must also
implement.
The Windows SDK does not actually have an IDL file for robuffer.h, and
its robuffer.h only defines the interface in C++. It also doesn't
declare an IID for this interface (only the UUID for __uuidof is
provided.)
The header generated from this IID should provide functionally identical
definitions as the one from Windows SDK. Additionally, it also provide
extra declarations including the IID and the C definition of the vtable
of IBufferByteAccess, which in theory would allow users to implement
this interface. But any user code that does this will be incompatible
with MSVC unless they provide compatible definitions themselves.
mingw-w64-headers/Makefile.am | 1 +
mingw-w64-headers/include/robuffer.idl | 28 ++
2 files changed, 29 insertions(+)
create mode 100644 mingw-w64-headers/include/robuffer.idl
diff --git a/mingw-w64-headers/Makefile.am b/mingw-w64-headers/Makefile.am
index ee3601209..dcdee4c03 100644
--- a/mingw-w64-headers/Makefile.am
+++ b/mingw-w64-headers/Makefile.am
@@ -252,6 +252,7 @@ IDL_SRCS = \
include/qedit.idl \
include/qnetwork.idl \
include/relogger.idl \
+ include/robuffer.idl \
include/rtworkq.idl \
include/vmr9.idl \
include/wincodec.idl \
diff --git a/mingw-w64-headers/include/robuffer.idl
b/mingw-w64-headers/include/robuffer.idl
new file mode 100644
index 0..cc9225627
--- /dev/null
+++ b/mingw-w64-headers/include/robuffer.idl
@@ -0,0 +1,28 @@
+/**
+ * This file has no copyright assigned and is placed in the Public Domain.
+ * This file is part of the mingw-w64 runtime package.
+ * No warranty is given; refer to the file DISCLAIMER.PD within this package.
+ */
+
+#ifdef __WIDL__
+#pragma winrt
+#endif
+
+import "objidl.idl";
+
+cpp_quote("#if NTDDI_VERSION >= NTDDI_WIN8")
+
+namespace Windows.Storage.Streams {
+
+[
+uuid(905a0fef-bc53-11df-8c49-001e4fc686da),
+]
+interface IBufferByteAccess : IUnknown
+{
+HRESULT Buffer([out, retval] byte **value);
+}
+
+}
+
+cpp_quote("STDAPI RoGetBufferMarshaler(IMarshal **bufferMarshaler);")
+cpp_quote("#endif")
--
2.39.0
_______
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] [PATCH] headers: Add shcore.h
Signed-off-by: Alvin Wong
---
Added according to
https://learn.microsoft.com/en-us/windows/win32/api/shcore/. These
functions are used for WinRT interop with IStream.
mingw-w64-headers/include/shcore.h | 33 ++
1 file changed, 33 insertions(+)
create mode 100644 mingw-w64-headers/include/shcore.h
diff --git a/mingw-w64-headers/include/shcore.h
b/mingw-w64-headers/include/shcore.h
new file mode 100644
index 0..bea583d5b
--- /dev/null
+++ b/mingw-w64-headers/include/shcore.h
@@ -0,0 +1,33 @@
+/**
+ * This file has no copyright assigned and is placed in the Public Domain.
+ * This file is part of the mingw-w64 runtime package.
+ * No warranty is given; refer to the file DISCLAIMER.PD within this package.
+ */
+
+#ifndef _SHCORE_H_
+#define _SHCORE_H_
+
+#include
+
+#if NTDDI_VERSION >= NTDDI_WIN8
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+typedef enum {
+BSOS_DEFAULT = 0,
+BSOS_PREFERDESTINATIONSTREAM,
+} BSOS_OPTIONS;
+
+STDAPI CreateRandomAccessStreamOnFile(PCWSTR filePath, DWORD accessMode,
REFIID riid, void **ppv);
+STDAPI CreateRandomAccessStreamOverStream(IStream *stream, BSOS_OPTIONS
options, REFIID riid, void **ppv);
+STDAPI CreateStreamOverRandomAccessStream(IUnknown *randomAccessStream, REFIID
riid, void **ppv);
+
+#ifdef __cplusplus
+}
+#endif
+
+#endif /* NTDDI_VERSION >= NTDDI_WIN8 */
+
+#endif
--
2.39.0
___
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] headers: Use Windows 10 as default _WIN32_WINNT value.
On Sat, 24 Dec 2022, LIU Hao wrote: > The only issue in this thread seems to be inside GNU lib because it relies on > the default value. That's probably not good; however, given GNU lib users are > less likely to be aware of this Windows-specific macro, maybe we can propose > GNU lib should set a default, safer value, if no one is given elsewhere. BTW I > do think that `_WIN32_WINNT` should always be set when compiling Windows code. Not just gnulib, but llvm's libc++ as well. There was discussion about possibly defining _WIN32_WINNT during libc++ build to win7 to allow the packaged binaries to continue to work there, but I don't know if there was a decision to do that, revert the default to win7, or just accept that our libc++ binaries won't work on win7 anymore. (I don't care at all about win 8.0, I don't know if anyone else does...) ___ 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] headers: Use Windows 10 as default _WIN32_WINNT value.
On Fri, 23 Dec 2022, Roger Pack wrote: > Ran into this. > According to > https://learn.microsoft.com/en-us/cpp/porting/modifying-winver-and-win32-winnt?view=msvc-170 > "The preprocessor macros WINVER and _WIN32_WINNT specify the minimum > operating system version your code supports." > > Anyway, setting this value to default to windows 10 caught me > recently, suddenly compiling gnutls doesn't work for windows 7 anymore > It uses Gnulib's gettimeofday.c internally, which links against the > windows 8' GetSystemTimePreciseAsFileTime if _WIN32_WINNT is set high > enough. I recently discovered that llvm's libc++ has something similar. MSYS2 recently bumped their default _WIN32_WINNT to Windows 8.1, and the libc++ built after that no longer worked on Windows 7. I was of the understanding that that macro was intended to be set by project code, and just controlled what APIs were made available by the headers, and the project code could simply not call anything from a newer version. But it seems that some projects treat it instead as telling *them* what APIs they can call, and that results in it being a minimum supported OS version. I didn't know MS explicitly called it out as such in a doc somewhere. _______ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] undefined reference for __mingw_vfprintf
I'm trying to build a program in Cygwin using the x86_64-w64-mingw32 stuff. When I compile and link my program just with x86_64-w64-mingw32-gcc.exe, it compiles and links fine. But when I try to use a makefile to compile and link in separate steps, it gives the following errors: $ make -f spi_comm.mkming-ld -o spi_comm.exe spi_comm.o "ftdi/libmpsse-windows-1.0.3/release/build/x64/libmpsse.lib"ming-ld: spi_comm.o:spi_comm.c:(.text+0x33): undefined reference to `__mingw_vfprintf'ming-ld: spi_comm.o:spi_comm.c:(.text+0x72): undefined reference to `__imp___acrt_iob_func'ming-ld: spi_comm.o:spi_comm.c:(.text+0x83): undefined reference to `__mingw_vfprintf'ming-ld: spi_comm.o:spi_comm.c:(.text+0x1b6): undefined reference to `__imp___acrt_iob_func'ming-ld: spi_comm.o:spi_comm.c:(.text+0x1e0): undefined reference to `exit'ming-ld: spi_comm.o:spi_comm.c:(.text+0x20f): undefined reference to `__imp___acrt_iob_func'ming-ld: spi_comm.o:spi_comm.c:(.text+0x239): undefined reference to `exit'ming-ld: spi_comm.o:spi_comm.c:(.text+0x245): undefined reference to `__imp___acrt_iob_func'ming-ld: spi_comm.o:spi_comm.c:(.text+0x263): undefined reference to `exit'ming-ld: spi_comm.o:spi_comm.c:(.text+0x27a): undefined reference to `__main'make: *** [spi_comm.mk:28: spi_comm.exe] Error 1 I suppose I need to name the mingw libraries to include at the linker step, but how can I identify which libraries are needed? There is quite a long list under /usr/x86_64-w64-mingw32/sys-root/mingw/lib. I've searched in vain for a solution to the __mingw_vfprintf library reference. Is there a standard C library that I should name for the linker? Thanks,Mark ___ 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] genstubdll: Remove
On 12/21/22 15:12, LIU Hao wrote: 在 2022-12-20 02:49, Pali Rohár 写道: And I think that this decision is independent of tool itself if should be removed too or not. My point is that if this should be removed then we shouldn't behave as if it was being actively maintained. Patch attached. Thoughts? Removal seems good to me. 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] widl: Avoid conflicting definitions of fastfail from Wine's winnt.h
Hi Martin, On 12/21/22 10:37, Martin Storsjö wrote: Widl uses a subset of Wine headers, on top of the host's platform headers (either Unix or Windows ones). When building widl for a Windows target, the included Wine headers end up being preferred over the toolchain's own platform headers. Wine defines the __fastfail function in the winnt.h header (as a static inline function), while mingw-w64 headers define it in _mingw.h as a extern gnu_inline function. When built with Clang, this combintion of an extern declaration and static inline, ends up producing extern definitions of the function in every compilation unit that ends up including both headers - which ends up as linker errors due to duplicate definitions. (GCC doesn't seem to produce any extern definitions in these cases.) Patch the imported winnt.h from Wine, to skip the definition of __fastfail if __MINGW_FASTFAIL_IMPL is defined (which is set by _mingw.h). In theory, Wine should support using its headers with mingw-w64 CRT headers, so it may be even fine for upstream. Or maybe we could move it from Wine winnt.h to something like corecrt.h. Anyway, I'm not sure about upstream Wine and it seems fine to me to just commit your patch to mingw-w64 widl for now. Thanks, 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] interface macro conflicts with interface variable
On 21/12/2022 16:45, LIU Hao wrote: If you define `WIN32_LEAN_AND_MEAN` (either `#define` it or pass `-DWIN32_LEAN_AND_MEAN` to GCC) before inclusion of , then the error will go away. This seems to be yet another reason why `WIN32_LEAN_AND_MEAN` should be preferred. ...which only works if you don't need to use any COM interfaces. `#include ` will bring back the `interface` macro. ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] [PATCH] headers: Add systemmediatransportcontrolsinterop.idl
Signed-off-by: Alvin Wong
---
mingw-w64-headers/Makefile.am | 1 +
.../systemmediatransportcontrolsinterop.idl | 15 +++
2 files changed, 16 insertions(+)
create mode 100644
mingw-w64-headers/include/systemmediatransportcontrolsinterop.idl
diff --git a/mingw-w64-headers/Makefile.am b/mingw-w64-headers/Makefile.am
index 6e026f19a..ee3601209 100644
--- a/mingw-w64-headers/Makefile.am
+++ b/mingw-w64-headers/Makefile.am
@@ -214,6 +214,7 @@ IDL_SRCS = \
include/spellcheck.idl \
include/strmif.idl \
include/structuredquerycondition.idl \
+ include/systemmediatransportcontrolsinterop.idl \
include/taskschd.idl \
include/textstor.idl \
include/thumbcache.idl \
diff --git a/mingw-w64-headers/include/systemmediatransportcontrolsinterop.idl
b/mingw-w64-headers/include/systemmediatransportcontrolsinterop.idl
new file mode 100644
index 0..265ae0536
--- /dev/null
+++ b/mingw-w64-headers/include/systemmediatransportcontrolsinterop.idl
@@ -0,0 +1,15 @@
+/**
+ * This file has no copyright assigned and is placed in the Public Domain.
+ * This file is part of the mingw-w64 runtime package.
+ * No warranty is given; refer to the file DISCLAIMER.PD within this package.
+ */
+
+import "inspectable.idl";
+
+[
+uuid(ddb0472d-c911-4a1f-86d9-dc3d71a95f5a),
+]
+interface ISystemMediaTransportControlsInterop : IInspectable
+{
+HRESULT GetForWindow([in] HWND appWindow, [in] REFIID riid, [out, retval,
iid_is(riid)] void **mediaTransportControl);
+}
--
2.38.1
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Mingw-w64 add support for riscv64?
Do you mean building a mingw-w64 cross compilation toolchain on riscv for cross-compiling on a riscv Linux host, or building a toolchain targeting Windows on riscv? The former (cross toolchain on riscv host) should not be much different than on other architectures. If you do encounter issues when building such toolchains (like issues building host tool) you are welcomed to ask for help, or submit patches if the issue is from inside mingw-w64. The latter is something that does not currently exist at all, and has no reason to exist. Until Microsoft actually publicly releases a build of Windows for riscv, I don't think there is anything for us to do in this regard. Cheers, Alvin On 13/12/2022 16:41, Bo YU wrote: hi Alvin, On Tue, Dec 13, 2022 at 4:30 PM Alvin Wong via Mingw-w64-public wrote: Hi, From my understanding, `mingw-w64-tools/widl` is imported from Wine, so any changes should be submitted to the other upstream: https://gitlab.winehq.org/wine/wine/-/blob/master/include/basetsd.h Thanks for correcting me about this. I will update the changes to wine. btw, about mingw-w64 to support riscv64, could you give some advices? maybe I just to try build it on riscv64 machines. But I think your help is very valuable. thank you. BR, Bo Cheers, Alvin On 13/12/2022 16:08, Bo YU wrote: Hi, I asked about the possibility on IRC about a few months ago, but the answer is not positive in my view. Recently I got some reports that some packages from others distro will depend on mingw-w64 on riscv64 arch. So I think it is better to support riscv64 from upstream. The patch I have submitted to Debian[0] is very simple but it can be built. If there is more to do please let me know, thanks. [0]: https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=1014392;filename=add-support-riscv64.patch;msg=15 BR, Bo ___ 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 ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Mingw-w64 add support for riscv64?
Hi, From my understanding, `mingw-w64-tools/widl` is imported from Wine, so any changes should be submitted to the other upstream: https://gitlab.winehq.org/wine/wine/-/blob/master/include/basetsd.h Cheers, Alvin On 13/12/2022 16:08, Bo YU wrote: Hi, I asked about the possibility on IRC about a few months ago, but the answer is not positive in my view. Recently I got some reports that some packages from others distro will depend on mingw-w64 on riscv64 arch. So I think it is better to support riscv64 from upstream. The patch I have submitted to Debian[0] is very simple but it can be built. If there is more to do please let me know, thanks. [0]: https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=1014392;filename=add-support-riscv64.patch;msg=15 BR, Bo ___ 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] Problems when building NT kernel drivers with GCC / LD
On 26.11.2022 20:04, Pali Rohár wrote: > On Monday 21 November 2022 08:24:36 Jan Beulich wrote: >> But then, with you replying to >> me specifically, perhaps you're wrongly assuming that I would be >> planning to look into addressing any or all of these? My earlier reply >> was merely to point out that _some_ work has already been done ... > > I added into CC also gcc, ld and mingw mailing list. If this is not > enough, could you tell me who to contact about those issues? That's probably enough, sure. I merely tried to set expectations right, since you did reply To: me (and lists were only on Cc: - it being the other way around would have demonstrated that you're not asking me specifically). Jan ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Problems when building NT kernel drivers with GCC / LD
On 20.11.2022 14:10, Pali Rohár wrote: > On Saturday 05 November 2022 02:26:52 Pali Rohár wrote: >> On Saturday 05 November 2022 01:57:49 Pali Rohár wrote: >>> On Monday 31 October 2022 10:55:59 Jan Beulich wrote: >>>> On 30.10.2022 02:06, Pali Rohár via Binutils wrote: >>>>> * GCC or LD (not sure who) sets memory alignment characteristics >>>>> (IMAGE_SCN_ALIGN_MASK) into the sections of PE executable binary. >>>>> These characteristics should be only in COFF object files, not >>>>> executable binaries. Specially they should not be in NT kernel >>>>> drivers. >>>> >>>> Like Martin pointed out in reply for another item, I'm pretty sure >>>> this one was taken care of in bfd already (and iirc is in 2.39). You >>>> fail to mention at all what versions of the various components you >>>> use. >>> >>> Ou, sorry for that. I take care to write issues in all details and >>> totally forgot to write such important information like tool versions. >>> >>> Now I retested all issues on Debian 11 which has LD 2.35.2 and GCC >>> 10.2.1 and all issues are there still valid except data characteristic >>> IMAGE_SCN_CNT_INITIALIZED_DATA for code sections IMAGE_SCN_CNT_CODE. >>> >>> I can easily retest it with LD 2.39 and GCC 10.3.0 which is in Debian >>> testing. >> >> Retested with LD 2.39 and GCC 10.3.0 which is in Debian testing and >> following problems are additionally fixed: --exclude-all-symbols, >> --dynamicbase and IMAGE_SCN_ALIGN_MASK (which you mentioned above). All >> other still reminds. >> >> Do you need some other information? > > Hello! I would like to ask if you need some other details or something > else for these issues. Well, generally speaking it might help if you could provide smallish testcases for every item individually. But then, with you replying to me specifically, perhaps you're wrongly assuming that I would be planning to look into addressing any or all of these? My earlier reply was merely to point out that _some_ work has already been done ... Jan ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Problems when building NT kernel drivers with GCC / LD
On 28.11.2022 09:40, Jonathan Wakely wrote: > On Mon, 28 Nov 2022, 08:08 Jan Beulich via Gcc, wrote: > >> On 26.11.2022 20:04, Pali Rohár wrote: >>> On Monday 21 November 2022 08:24:36 Jan Beulich wrote: >>>> But then, with you replying to >>>> me specifically, perhaps you're wrongly assuming that I would be >>>> planning to look into addressing any or all of these? My earlier reply >>>> was merely to point out that _some_ work has already been done ... >>> >>> I added into CC also gcc, ld and mingw mailing list. If this is not >>> enough, could you tell me who to contact about those issues? >> >> That's probably enough, sure. I merely tried to set expectations right, >> since you did reply To: me (and lists were only on Cc: - it being the >> other way around would have demonstrated that you're not asking me >> specifically). >> > > That's just how most mailers do "Reply All", I don't think it out implies > anything. I know mailers behave that way. But when replying you can adjust To: vs Cc:. That's what I'm doing all the time (or at least I'm trying to remember to do so), because it makes a difference to me whether mail is sent To: me vs I'm only being Cc:-ed. Otherwise - why do we have To: and Cc: as different categories? > Removing the Cc list and *only* replying to you would be different. Sure - that would have meant sending private mail, which is yet worse. Jan ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] gcc parameter -mcrtdll= for choosing Windows C RunTime DLL library
On 12/4/22 12:48, LIU Hao wrote: 在 2022-12-04 20:16, Pali Rohár via Gcc 写道: Hello! I would like to ask gcc people, what do you think about such proposed -mcrtdll= parameter? There are lot of unofficial gcc patches which implement this -mcrtdll= parameter and this parameter is present in more gcc forks. So it looks like that this parameter is useful for more people. I vote +1 for this in GCC 14. GCC 13 (i.e. current master branch) is at stage3 so it's not an option at this moment. I've been silent all this time because personally I'm rather ambivalent about it. It will make users think they can just switch and jump to another runtime without any downsides, only to hit a brick wall when they mix them together, and then blame this as a GCC bug. Especially when they try this with C++. ___ 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 v3] headers: Implement quaternion functions in windowsnumerics.h
Thanks, looks good to me. On 25/11/2022 5:25, Martin Storsjö wrote: Also implement a couple make_float4x4_* functions that are useful for constructing input for some tests. This reduces the number of unimplemented functions in this header a little bit. Signed-off-by: Martin Storsjö --- v3: Left out the float4x4 decompose function from this patch. --- .../include/windowsnumerics.impl.h| 160 +++--- .../testcases/test_windowsnumerics.cpp| 104 +++- 2 files changed, 244 insertions(+), 20 deletions(-) ___ 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] headers: Implement quaternion functions in windowsnumerics.h
On 22/11/2022 20:07, Martin Storsjö wrote:
+ inline bool decompose(const float4x4 , float3 *out_scale, quaternion
*out_rot, float3 *out_translate) {
+float4x4 val = mat;
+if (out_translate)
+ *out_translate = translation(val);
+val.m41 = val.m42 = val.m43 = 0.0f;
+float3 scale = float3(
+ length(float3(val.m11, val.m12, val.m13)),
+ length(float3(val.m21, val.m22, val.m23)),
+ length(float3(val.m31, val.m32, val.m33))
+);
+if (out_scale)
+ *out_scale = scale;
+val = make_float4x4_scale(float3(1.0f/scale.x, 1.0f/scale.y,
1.0f/scale.z)) * val;
+if (out_rot)
+ *out_rot = make_quaternion_from_rotation_matrix(val);
+return true;
+ }
I feel that there should be some conditions that cause this function to
return false, if the input is not a scale/rotate/translate matrix...
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
