Re: [Mingw-w64-public] [PATCH v2 1/3] headers: Use the __MINGW_(MS|GNU)_(PRINTF|SCANF) macros
Hi, The series 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] [PATCH] headers: Use asm() for redirecting time functions, instead of inline functions
On 8.05.2024 14:22, Martin Storsjö wrote: Prior to 1652e9241b5d8a5a779c6582b1c3c4f4a7cc66e5, the inline functions always were static. Due to reexporting such symbols in C++20 modules (for the C++23 std module), the reexported symbols must not be static, so the inline functions were changed from static inline to __mingw_ovr, which practically is static inline in C mode, but regular inline in C++ mode. By using regular inline in C++ mode, each use of the functions can (but doesn't need to) emit an external symbol for the inline function, and the callers may either call that function or inline the body of the function. This can have two potential issues; if different translation units are configured differently (with the _USE_32BIT_TIME_T define), but both use the same external symbol for it, the linker will only keep one of them (as they're both inline, and supposed to be the same). In practice, this is rare for _USE_32BIT_TIME_T though. Secondly, such an external symbol may conflict with the actual import library. Such a case was reported at https://github.com/mstorsjo/llvm-mingw/issues/427. (Practically, the issue there was that some built object files defined an external "_time" symbol, i.e. regular "time" with i386 cdecl underscore prefix, from the non-static inline functions. The object also files reference _time32 with dllimport, which via the weak aliases produced by llvm-dlltool end up pulling in the __imp__time symbol, which also brings in a conflicting "_time" symbol.) In short - inline functions can be problematic. Where possible, it's less problematic to use asm(), via __MINGW_ASM_CALL(), to redirect calls directly towards the right function. This has a slight drawback, that this ends up calling the thunks (as the declarations lack dllimport), while we previously could inline the call directly to a dllimported function (avoiding the thunk, fetching the target address via the __imp_ prefixed symbol). We could, easily, add the dllimport attributes on these declarations, but that triggers a GCC bug for how those symbol names are mangled on i386, see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114984. (The bug seems to be noted and mentioned as early as 2007, in https://sourceware.org/pipermail/cygwin/2007-February/154845.html, but it doesn't seem to have been fixed since.) Signed-off-by: Martin Storsjö --- mingw-w64-headers/crt/time.h | 62 1 file changed, 28 insertions(+), 34 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] [PATCH 10/10] crt: Move find, stat and time aliases to def-include/msvcrt-common.def.in
On 26.04.2024 21:43, Pali Rohár wrote: I played a bit with different msvc 19.x versions and 32-bit x86 variant recognize time symbol and maps it to _time32 at link time. First compiler maps time symbol to _time and then linker maps _time to __time32. It means that msvc import libraries have symbol "time" as alias to "_time32" function. It can be easily played with it on godbolt: https://godbolt.org/z/PT6WzEoaP After adding #include for proper time() declaration, msvc translated at compile time it to _time64 symbol. And linker resolved _time64 to __time64. https://godbolt.org/z/1YY557ePK So this shows that msvc "time" symbol in x86 32-bit object files uses 32-bit time_t type. It means that 64-bit time_t type is enforced by the compiler which emits _time64 symbol. Good point, that's not what I expected. Changing that seems fine to me then (as Martin said, separated from refactoring). 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 10/10] crt: Move find, stat and time aliases to def-include/msvcrt-common.def.in
On 25.04.2024 23:11, Pali Rohár wrote: And also it would allow to create object file which calls "_findfirst" symbol and then link it with any mingw-w64 CRT import library. Mixing crts is problematic for many reasons, this is just one of them. And if one really needs to go that far, it's better to just use *32 or *64 variant explicitly, which would entirely avoid the confusion and should be possible with current crt. I think it is better to have stable symbol meaning than to have symbol alias matching what the headers default to. Stable symbol meaning can be an invariant in this case. But symbol matching with header file is not stable as application can change it by -D_USE_32BIT_TIME_T. What do you think? Does it make sense? Sure, an application can change it on per-file basis, but it's way more likely that it doesn't and just uses the default. If we provide a different default behavior in headers, why wouldn't we reflect that in crt part? Having those consistent seems more important than a compatibility with some unsupported use cases. 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 5/5] headers: Stop using the __mingw_static_ovr macro
Hi Martin, Patches look 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] Rust test failure after some math functions were moved
On 23.04.2024 13:39, Martin Storsjö wrote: On Tue, 16 Apr 2024, Jacek Caban wrote: 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. Unfortunately, we can't really do this; __sinl_internal and __cosl_internal are used by both math/x86/sin.c and math/x86/cos.c, which are in src_msvcrt_common_add_x86 (i.e. in the msvcr* specific import libraries), but they're also used by math/x86/sinl.c and math/x86/cosl.c, which are in src_libmingwex_x86, because the long double form of them are needed even with UCRT. Oh right, we'd be missing it in UCRT. It seems that the most reliable fix is on Rust side. 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
On 16.04.2024 17:29, philippe renon wrote: 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 I know, but only the ones that depend on mingwex are a problem, are there others like that? 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
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 diff --git a/mingw-w64-crt/Makefile.am b/mingw-w64-crt/Makefile.am index b104270c3..17eaefac2 100644 --- a/mingw-w64-crt/Makefile.am +++ b/mingw-w64-crt/Makefile.am @@ -226,6 +226,7 @@ src_msvcrt_common_add_x86=\ math/x86/remquo.S math/x86/remquof.S \ math/x86/rint.c math/x86/rintf.c \ math/x86/sin.c \ + math/x86/sinl_internal.S \ math/x86/trunc.S math/x86/truncf.S \ \ math/x86/acosf.c \ @@ -796,7 +797,7 @@ src_libmingwex_x86=\ math/x86/remainderl.S math/x86/remquol.S\ math/x86/scalbn.S math/x86/scalbnf.Smath/x86/scalbnl.S\ math/x86/sin.def.h\ - math/x86/sinl.c math/x86/sinl_internal.S math/x86/tanl.S + math/x86/sinl.c math/x86/tanl.S src_libmingwex32=$(src_libmingwex_x86) diff --git a/mingw-w64-crt/Makefile.in b/mingw-w64-crt/Makefile.in index fff4ec286..ef194d928 100644 --- a/mingw-w64-crt/Makefile.in +++ b/mingw-w64-crt/Makefile.in @@ -907,13 +907,13 @@ am__lib32_libmingwex_a_SOURCES_DIST = cfguard/mingw_cfguard_support.c \ math/x86/logl.c math/x86/nearbyintl.S math/x86/pow.def.h \ math/x86/powl.c math/x86/remainderl.S math/x86/remquol.S \ math/x86/scalbn.S math/x86/scalbnf.S math/x86/scalbnl.S \ - math/x86/sin.def.h math/x86/sinl.c math/x86/sinl_internal.S \ - math/x86/tanl.S math/DFP/__fpclassifyd32.c \ - math/DFP/__fpclassifyd64.c math/DFP/__fpclassifyd128.c \ - math/DFP/__isnand32.c math/DFP/__isnand64.c \ - math/DFP/__isnand128.c math/DFP/__signbitd32.c \ - math/DFP/__signbitd64.c math/DFP/__signbitd128.c \ - math/DFP/isinfd32.c math/DFP/isinfd64.c math/DFP/isinfd128.c + math/x86/sin.def.h math/x86/sinl.c math/x86/tanl.S \ + math/DFP/__fpclassifyd32.c math/DFP/__fpclassifyd64.c \ + math/DFP/__fpclassifyd128.c math/DFP/__isnand32.c \ + math/DFP/__isnand64.c math/DFP/__isnand128.c \ + math/DFP/__signbitd32.c math/DFP/__signbitd64.c \ + math/DFP/__signbitd128.c math/DFP/isinfd32.c \ + math/DFP/isinfd64.c math/DFP/isinfd128.c @CFGUARD_TRUE@am__objects_22 = cfguard/lib32_libmingwex_a-mingw_cfguard_loadcfg.$(OBJEXT) am__objects_23 = \ cfguard/lib32_libmingwex_a-mingw_cfguard_support.$(OBJEXT) \ @@ -1230,7 +1230,6 @@ am__objects_24 = math/lib32_libmingwex_a-cbrtl.$(OBJEXT) \ math/x86/lib32_libmingwex_a-scalbnf.$(OBJEXT) \ math/x86/lib32_libmingwex_a-scalbnl.$(OBJEXT) \ math/x86/lib32_libmingwex_a-sinl.$(OBJEXT) \ - math/x86/lib32_libmingwex_a-sinl_internal.$(OBJEXT) \ math/x86/lib32_libmingwex_a-tanl.$(OBJEXT) am__objects_25 = $(am__objects_24) @ENABLE_DFP_TRUE@am__objects_26 = math/DFP/lib32_libmingwex_a-__fpclassifyd32.$(OBJEXT) \ @@ -1437,11 +1436,11 @@ am__lib32_libmsvcrt_common_a_SOURCES_DIST = misc/mbrtowc.c \ math/x86/logbf.c math/x86/nearbyint.S math/x86/nearbyintf.S \ math/x86/pow.c math/x86/remainder.S math/x86/remainderf.S \ math/x86/remquo.S math/x86/remquof.S math/x86/rint.c \ - math/x86/rintf.c math/x86/sin.c math/x86/trunc.S \ - math/x86/truncf.S math/x86/acosf.c math/x86/asinf.c \ - math/x86/atan2f.c math/x86/atanf.c math/x86/ceilf.S \ - math/x86/cosf.c math/x86/floorf.S math/x86/fmodf.c \ - math/x86/sinf.c math/x86/tanf.c + math/x86/rintf.c math/x86/sin.c math/x86/sinl_internal.S \ + math/x86/trunc.S math/x86/truncf.S math/x86/acosf.c \ + math/x86/asinf.c math/x86/atan2f.c math/x86/atanf.c \ + math/x86/ceilf.S
Re: [Mingw-w64-public] [PATCH 1/3] include: Import dyngraph.idl from wine
Looks good, I pushed the series. 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] tools: Remove hardcoded use of -Werror
On 6.02.2024 13:22, Martin Storsjö wrote: By hardcoding the use of -Werror, we risk that the build can break on any newer (or older) toolchain which can give warnings for unexpected issues. Fixing such issues is of course desired, but we shouldn't be breaking the build universally, unless the user explicitly has asked for this behaviour. Agreed, 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] [PATCH] headers: Adjust __cpuidex availability for Clang
On 5.02.2024 23:27, Martin Storsjö wrote: Clang 18.x was meant to implement __cpuidex (a version was merged during the development of Clang 17.x, but it was reverted and backed out before Clang 17.x was completed) - however it was never merged before Clang 18.x was branched after all. For further history of the earlier changes within mingw-w64, see 0605217f5d60257a53ec875e2e4ff36a3e14f825 and 2b6c9247613aa830374e3686e09d3b8d582a92a6. Postpone this change to Clang 19 for now. This fixes building software that uses __cpuidex with Clang 18. Hopefully it can either be merged in Clang well in advance before Clang 19 gets branched, or this issue revisited again long before that. Signed-off-by: Martin Storsjö --- mingw-w64-headers/include/psdk_inc/intrin-impl.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) 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] [PATCH] headers: Make getopt.h react to _BSD_SOURCE after being included once first
On 20.12.2023 14:32, Martin Storsjö wrote: For definitions like _BSD_SOURCE, the most failsafe solution generally is to define them before including any header, to avoid this kind of issue. However, allowing getopt.h to react to being reincluded with _BSD_SOURCE defined, is quite straightforward. Agreed, this is straightforward enough. 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] headers: Import mfmediaengine.idl from wine.
On 29.11.2023 18:35, Nikolay Sivov wrote:
import "mfobjects.idl";
+import "mftransform.idl";
cpp_quote("#include ") // FIXME: import "mftransform.idl";
This cpp_quote should be removed now. I fixed that and 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] [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 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 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] 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] [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_msvcrt_version=0x700 ;; +ucrt*|*) +
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 +178,12 @@ msvcr110*) msvcr120*)
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 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
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] 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
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: 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] 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] 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] [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] Adding a new thread model to GCC
On 11/15/22 15:17, LIU Hao wrote: I think that when there is a real bug, we should fix it. As for standard themselves, I think that C/C++ standards are important. Praising POSIX-alike standards for mingw-w64, who's CRT is a wrapper around Windows system CRT, seems a bit misplaced for me. Using it makes sense sometimes, but I don't think it should be a goal on its own. For full POSIX compatibility, one needs something like Cygwin, MSYS or WSL2 anyway. Do we conclude that we shouldn't introduce the extra complexity, and should just maintain the same behavior as MSVC, although it's non-standard and causes deadlocks or crashes occasionally? This decision is reasonable on itself; and if that is the decision, then fair enough. As I mentioned, I think that real bugs should be fixed. But we need proper understanding of the problem and find root of it. For example you said that: > 1. In a DLL, destructors of static objects and callbacks that are registered > with `atexit()`, are executed by `LdrShutdownProcess()`, after all the other > thread have been terminated `ZwTerminateProcessO(NULL, status)`. This means > that, if another thread has been terminated while holding a mutex, the mutex > can never get unlocked. If a destructor attempts to lock the same mutex, > deadlocks will occur. Destructors of executables do not suffer from this > issue, because they are executed before `RtlExitUserProcess()`. This is simply not true when msvcrt is properly used. atexit callbacks are executed by msvcrt before calling ExitProcess(), see Wine implementation (callbacks are invoked by _cexit()): https://gitlab.winehq.org/jacek/wine/-/blob/master/dlls/msvcrt/exit.c#L364 It's possible that mingw-w64 does not use it properly, but in that case we should identify the exact problem and simply use it properly. 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] Adding a new thread model to GCC
On 11/14/22 09:57, LIU Hao wrote: 在 2022/10/25 04:50, Jacek Caban 写道: This also may be supported in existing threading models. Overflow is trivial to fix by waiting in a loop. (There are other reasons why OS support for absolute timeout is slightly better, but the price of this design decision makes it questionable. I plan to elaborate more on that on mingw ML, but I need to find time to do a bit of research first). What's the status of your 'a bit of research'? This looks like procrastination to me. I was short on spare time lately, my apologies. I was planning to learn your code to have more insightful comments, but it requires non-trivial amount of time that I couldn't allocate. Anyway, I don't think there is any procrastination, your threading model is merged after all. Meantime, Eric updated his patches on gcc-patches. I wonder what's the next step for them? Jon? Do you (and some others) consider standard conformance not-a-thing; or should we maintain such bug-to-bug compatibility, letting users to solve such issues themselves? I think that when there is a real bug, we should fix it. As for standard themselves, I think that C/C++ standards are important. Praising POSIX-alike standards for mingw-w64, who's CRT is a wrapper around Windows system CRT, seems a bit misplaced for me. Using it makes sense sometimes, but I don't think it should be a goal on its own. For full POSIX compatibility, one needs something like Cygwin, MSYS or WSL2 anyway. Unless it's not clear, I appreciate your efforts to fix things. I just don't agree that some (admittedly important) implementation details are the best way to fix them. 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] Adding a new thread model to GCC
On 10/24/22 05:40, LIU Hao via Gcc-patches wrote: 在 2022/10/21 20:34, i.nix...@autistici.org 写道: got it... anyway it seems logical to me the way I proposed :) Below is a message forwarded from mingw-w64-public, elaborating the necessity of a new thread model. As there are objections from other mingw-w64 developers, I am putting those patches against mingw-w64-crt on hold for now. Despite that, all threading facilities - mutexes, condition variables, once flags, etc. - are still fully functional within the mcf thread model. In addition, I will keep maintaining my personal builds (from GCC 12 release branch) with these patches at https://gcc-mcf.lhmouse.com/. Forwarded Message 在 2022/10/23 18:06, Jacek Caban 写道: > > Please, let's not do that. It's possible to fix existing implementations, we don't need to make > things more complicated than they are. > Okay okay, I think I have to compose a thorough list of problems that we are facing at the moment, and had better have a permalink to the mailing list archive that I can reference elsewhere. I have been tired of repeating the same grounds of arguments again and again: 1. In a DLL, destructors of static objects and callbacks that are registered with `atexit()`, are executed by `LdrShutdownProcess()`, after all the other thread have been terminated `ZwTerminateProcessO(NULL, status)`. This means that, if another thread has been terminated while holding a mutex, the mutex can never get unlocked. If a destructor attempts to lock the same mutex, deadlocks will occur. Destructors of executables do not suffer from this issue, because they are executed before `RtlExitUserProcess()`. Standard behavior: Static destructors and exit callbacks should be executed while other threads are running. If another thread attempts to access a destroyed object, the behavior is undefined; the user is responsible to prevent this from happening, by joining or suspending it. 2. Following 1, in a DLL, static destructors and exit callbacks are still invoked when `_Exit()` or `quick_exit()` is called. Standard behavior: `_Exit()` should not perform any cleanup; not even open files are flushed. `quick_exit()` shall invoke all quick-exit callbacks in reverse order, then call `_Exit()`. 3. There is a use-after-free bug [1] about thread-local destructors. I suspect this is caused by emutls, because GCC uses `__cxa_thread_atexit()` to register thread-local destructors, which could interleave with `emutls_destroy()`. Standard behavior: This is not allowed to happen. mcfgthread solves this issue by running thread-local destructors and thread-specific key destructors as two separate passes [3]. [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80816 [2] https://github.com/gcc-mirror/gcc/blob/f84e4fb44aa26b71fbc64e0532fd24d96e5caa3f/libgcc/emutls.c#L96 [3] https://github.com/lhmouse/mcfgthread/blob/63e034d375caf585e2921cd3455f1048feb2172d/src/xglobals.c#L249 4. In the win32 thread model, thread-specific key destructors are called at process exit [4], after static destructors. Standard behavior: They shall be called only when a thread exits, and the associated thread-specific values are not a null pointer. They shall not be called when a program terminates; instead, users are responsible for deallocating such resources before calling `exit()`. This requirement is missing in POSIX, but formally specified by ISO/IEC 9899:2017, as the 4th paragraph in '7.26.6.1 The tss_create function'. [4] https://github.com/mingw-w64/mingw-w64/blob/d0a034a04d312434b842c4869a8a900568d8db98/mingw-w64-crt/crt/tlsthrd.c#L134 Those 4 points describes problems that you solve in the new threading model, but there is no reason they can't be fixed for existing threading models. In fact, ideally they would be fixed for all threading models. Except now we need to worry about one more threading model, meaning that future bugs will be even harder to fix. 5. Wait operations, of timed mutexes and condition variables, should take absolute time points as `struct timespec`. Standard behavior: Both POSIX and ISO C specifies them as such, while all Windows APIs take relative durations as a 32-bit integer of milliseconds, which can also easily get overflown. This also may be supported in existing threading models. Overflow is trivial to fix by waiting in a loop. (There are other reasons why OS support for absolute timeout is slightly better, but the price of this design decision makes it questionable. I plan to elaborate more on that on mingw ML, but I need to find time to do a bit of research first). 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: Implement standard-conforming termination support with mcfgthread
On 10/23/22 10:28, LIU Hao wrote: 在 2022-10-23 10:16, JonY via Mingw-w64-public 写道: On 10/22/22 19:52, Martin Storsjö wrote: On Sat, 22 Oct 2022, Jacek Caban wrote: Perhaps to a little surprise, I don't like it. My main issue is that it requires mingw crt to be aware of 3rd party library details instead of being agnostic to threading model. Just for the record - I totally agree with Jacek here (and with Jacek, Nixman and the others on gcc-patches). My long-term plan is to commit mcfgthread into 'mingw-w64-libraries' with generated configure scripts if they're desired, so it will be available as part of mingw-w64, just as winpthreads. Please, let's not do that. It's possible to fix existing implementations, we don't need to make things more complicated than they are. 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: Implement standard-conforming termination support with mcfgthread
On 10/23/22 04:16, JonY via Mingw-w64-public wrote: On 10/22/22 19:52, Martin Storsjö wrote: On Sat, 22 Oct 2022, Jacek Caban wrote: On 10/22/22 18:34, LIU Hao wrote: Hello, Attached are final patches for mcfgthread support in the CRT. Please review. Perhaps to a little surprise, I don't like it. My main issue is that it requires mingw crt to be aware of 3rd party library details instead of being agnostic to threading model. Just for the record - I totally agree with Jacek here (and with Jacek, Nixman and the others on gcc-patches). // Martin I also think this is a bit too invasive for the base crt libraries, if anything. I was hoping mcfgthread in gcc would be an in-development model as a preview of things to come, where things are expected to change and ABI to break, with the regular win32 thread as the stable model. That's pretty well understood at this point. We have LLVM libc++ implementation, Wine msvcp* implementation and even open sourced MS msvcp implementation. They all mostly agree on primitives used to implement threading support. There are even patches for libgcc that implement it the right way, but they were never merged. mcfgthread uses a very different approach, reimplementing things instead of using OS support. I still haven't heard a single sensible good reason to do that (and the reason given on gcc-patches is simply not true, as I explained there). 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: Implement standard-conforming termination support with mcfgthread
On 10/22/22 18:34, LIU Hao wrote: Hello, Attached are final patches for mcfgthread support in the CRT. Please review. Perhaps to a little surprise, I don't like it. My main issue is that it requires mingw crt to be aware of 3rd party library details instead of being agnostic to threading model. 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] [RFC] Integrating mcfgthread with mingw-w64 CRT
Hi, I heard that it was committed to GCC. I just want to mention for the record that I still think it was a mistake. I also think that obfuscating mingw-w64 with proposed changes would be a mistake. On 10/13/22 04:09, LIU Hao wrote: 在 2022/10/13 01:15, Jacek Caban 写道: I'd argue that this requirement will need to be relaxed at some point and fixing threading support would be a good reason to do that. If someone really wants win9x, winpthreads could still be used (or simply one could use an older version of GCC). This is valid on its own. However extending or modifying the win32 thread model is risky on almost all aspects: * Backward compatibility, because it's default on some platforms e.g. Debian; * Availability, because it will drop support for XP; * Stability, because some people may disagree with me on use of some undocumented APIs. If we follow that logic, we'd never change existing code or move forward. My opinion is that a 'clean', better designed solution should be preferred to such boilerplate code. Well, I don't think that the proposed solution is clean. Cheers, 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] [RFC] Integrating mcfgthread with mingw-w64 CRT
On 10/12/22 06:06, LIU Hao wrote: 在 2022/10/12 03:55, Jacek Caban 写道: Is there anything that mcfgthread achieves that can't be fixed in GCC's win32 model? This sounds to me like that GCC is the right place to fix things, possibly by merging parts of mcfgthread into GCC itself. I really don't like the idea of adding another threading model instead of fixing the existing one. It adds more fragmentation, more maintenance and more user confusion. I think it's better to fix the root of threading support problems instead. The obvious problem is that mcfgthread is functional on only Windows 7 and above, while (I don't know for sure) win32 should continue to work on XP, 2000, or even 9x. I'd argue that this requirement will need to be relaxed at some point and fixing threading support would be a good reason to do that. If someone really wants win9x, winpthreads could still be used (or simply one could use an older version of GCC). Originally there was only mutex, condition variable, once flag, thread and thread-specific key in mcfgthread. When I considered that it should be possible to join with the main thread from another one, it would be necessary to have a static thread-control structure for the main thread, allocated upon library initialization. (N.B. The Windows thread exit code is not an option, because pthread wants a `void*` which would be truncated on 64-bit Windows.) Later, `__cxa_atexit()` was added to address the issue about order of destruction, which also required a destructor queue. The same went for `__cxa_at_quick_exit()`. While some people do prefer static linking, ideally these global data should be unique within a single process, and were necessary to be part of a DLL. This approach was much similar to the legacy `mingwthrd` library. Technically, this can be solved with named shared memory [1], and is not a requirement any more. It should be possible to implement that without a custom thread-control structure, Windows API combined with msvcrt (urct) provides means for achieving that. Therefore it has become a personal preference, to not maintain something as a part of GCC, mostly due to their lack of enthusiasm about Windows. Well, sure, but that's not a technical argument. 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] [RFC] Integrating mcfgthread with mingw-w64 CRT
On 10/7/22 17:47, LIU Hao wrote: While mingw-w64 might have been deemed to enable projects, which typically build with the Microsoft compiler and linker, to build with the GNU compiler and linker with little modification, sometimes I do think we have payed too much in mimicking some non-standard, weird, or even broken behaviors [1] [2]. If, for some necessary reasons, we can't fix them, it might be possible to build up a new series of APIs according to the C, POSIX, and Itanium ABI [3] standards. Is there anything that mcfgthread achieves that can't be fixed in GCC's win32 model? This sounds to me like that GCC is the right place to fix things, possibly by merging parts of mcfgthread into GCC itself. I really don't like the idea of adding another threading model instead of fixing the existing one. It adds more fragmentation, more maintenance and more user confusion. I think it's better to fix the root of threading support problems instead. (As a side note, the way winpthreads is hooked into GCC also does not seem right to me. It would be fine as a stand-alone compatibility library, but hooking it into GCC is just a hack: it replaces win32 threading model instead of fixing root of the problem). 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: Fix PROCESS_MITIGATION_DYNAMIC_CODE_POLICY in winnt.h
On 9/19/22 13:38, Yannis Juglaret wrote: This fixes the struct used to enable the Arbitrary Code Guard mitigation or query its status on Windows. The size of the struct was wrong, which could lead calls to Get/SetProcessMitigationPolicy to fail with the last error set to ERROR_INVALID_PARAMETER. Signed-off-by: Yannis Juglaret Looks good to me, I pushed it. 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] #943 __mingw_printf() does not print non-ASCII chars correctly.
On 8/14/22 10:20, Takashi Yano wrote: On Sun, 14 Aug 2022 17:09:44 +0900 Takashi Yano wrote: I have built the partially fixed version (v6) attached, where only printf, *putw* and fwrite are fixed, as well as the fully fixed version (v7) attached. v7 patch is the modification of v5 where the workaround code is moved into libmsvcr*.a from libmingwex.a. With v6 patch, printf and Case 1, 3 works correctly as well as c++ ostream, while v7 patch works fine in every test case I can think of. v7 patch seems to be lost. I resent it. FWIW, I agree with previous opinions that this approach is way too invasive. Maybe you could make it less invasive by limiting its scope to __USE_MINGW_ANSI_STDIO or something along those lines. But honestly, I'm not sure we should try to work around Microsoft's bugs like that. It comes with a serious price of complicating the code and it will always be a hack one way or another. Proper fix requires modifying Microsoft part of CRT, it's already fixed properly by Microsoft in UCRT and we support building with UCRT. 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: Modernize the NAN constants returned by the nan*() functions
On 8/12/22 11:15, Martin Storsjö wrote: Don't return NAN constants with the sign bit set. This matches what UCRT returns for the nan*() functions since UCRT was introduced. It also matches the _Nan constant provided in older versions of MSVC (at least since 2003) (which are returned by various functions). Only in MSVC 6, I found NAN constants that had the sign bit set, matching what we had (with the intent to match MSVC). Thus, I think it's better for us to match the behaviour of modern MSVC (2003 and forward) than the legacy behaviour of MSVC 6 in this aspect. The patch itself looks good to me. I wonder, through, if we could just get rid of those internal defines and just use NAN instead. 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] How to fix error with macros in d3d12?
On 7/25/22 00:10, Zebediah Figura wrote: (+ wine-devel) On 6/11/22 13:26, LIU Hao wrote: 在 2022-06-12 01:59, Zebediah Figura 写道: The combination of `extern` with `__gnu_inline__` is necessary to suppress generation of a function body if the attached function could not be inlined when compiling as C99. Why do we need that? Otherwise there would be errors about multiple definitions. I don't think there is anything we can do with these headers. Perhaps WIDL should not generate `static` for `FORCEINLINE` functions; or, if that is not an option, `static __inline__` might be a better alternative. Is it legal to use 'static __forceinline' or 'extern __forceinline' with MSVC? If so I imagine we should find a solution that allows them. Yes, unfortunately. I don't think there is a solution. `extern inline` and `inline` are not equivalent in C. Right, so, apparently MSVC treats both "inline" and "__forceinline" as magic bullets—they can both appear with or without 'static' and 'extern'; they'll always generate a function body but can also be defined in multiple source files (in fact, if the definition differs and the functions aren't static, an arbitrary one is picked and no warning is even printed.) And for good measure you can always take the address too. [So as far as I can tell there's no difference between "inline" and "extern inline" as far as MSVC is concerned.] I guess we can't do anything about that without modifying the language. But of course in lieu of that we should probably fix our headers. I see at least three options: (1) Use "FORCEINLINE" instead of "static FORCEINLINE" for these functions. MSVC never uses FORCEINLINE with static or extern, so this would be more consistent. The downside is we'd need to provide import library definitions for all of these functions, though, which seems less than ideal. (Unless combined with option 3 below.) (2) Use "static inline" for COM wrappers. This of course drops the __always_inline__ attribute. I'm inclined to assert that's a non-issue, but then again I never really saw the point of __always_inline__ anyway. [I guess it can be used to force the compiler to inline even when -finline isn't enough, but surely that would never be the case here...] (2b) Or use "static inline __attribute((__always_inline__))", and define a new macro to encapsulate that. (3) Define __forceinline as "static inline" rather than "extern inline". I have to assume there was a reason this wasn't done in the first place, but there's no documentation in the file and I couldn't easily find discussion about it. As far as I can tell this actually matches MSVC almost exactly, except that multiple definitions will be generated if something takes the function address. That is arguably a break in behaviour which is worse than just failing to link, though. I recall attempts to improve it in mingw-w64, but I think they always hit one or another compatibility limitations (see commit 5255bcfd21 for an example). My long term preferred solution would be: (4) Have proper compiler support for __forceinline (probably in form of __attribute__((__forceinline__)) I think my preferred solution is 2 (or 2b I guess). I'm planning to send the attached patch to winehq (since we need to sync widl from there), but I'd like to hear some feedback from the mingw-w64 project first. FWIW, the patch seems fine 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] x64 longjmp and -fno-asynchronous-unwind-tables
On 7/13/22 11:45, Ozkan Sezer wrote: On 7/13/22, LIU Hao wrote: 在 2022/7/12 15:50, Ozkan Sezer 写道: With the patch applied to v5.x branch and crt rebuilt, the game engine rebuilt with -fno-asynchronous-unwind-tables in the CFLAGS against the newly built crt and setjmp.h seems to behave as it is supposed to when it hits longjmp. Do the patches replace `setjmp()` with something that does not unwind the stack? Looks so but it was not I that authored the patches, so... Yes. CC'ing Martin and Jacek. Patches against branches v6.x to v2.x re-attached. I think that those patches are too invasive for stable branches, especially very old ones like v2. 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: Add dxcore.idl
Hi Biswapriyo, On 6/17/22 09:38, Biswapriyo Nath wrote: mingw-w64-crt/libsrc/dxguid.c| 1 + mingw-w64-headers/Makefile.am| 1 + mingw-w64-headers/include/dxcore.idl | 195 +++ 3 files changed, 197 insertions(+) create mode 100644 mingw-w64-headers/include/dxcore.idl We import vast majority of DX headers from Wine and Wine will also be interested in having this IDL. I think it would make things more consistent if we use wine-import.sh for this IDL. 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] unknownbase.idl: Declare IUnknown proxy and stubs in C variant as well.
On 6/15/22 07:47, LIU Hao wrote: 在 2022/6/14 00:33, Jacek Caban 写道: Signed-off-by: Jacek Caban --- mingw-w64-headers/include/unknwnbase.idl | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) LGTM. THanks. Thanks, I pushed it. 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] unknownbase.idl: Declare IUnknown proxy and stubs in C variant as well.
Signed-off-by: Jacek Caban
---
mingw-w64-headers/include/unknwnbase.idl | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/mingw-w64-headers/include/unknwnbase.idl b/mingw-w64-headers/include/unknwnbase.idl
index a479baac1..a69a50468 100644
--- a/mingw-w64-headers/include/unknwnbase.idl
+++ b/mingw-w64-headers/include/unknwnbase.idl
@@ -36,18 +36,18 @@ interface IUnknown {
cpp_quote(" };")
cpp_quote("}")
cpp_quote("__CRT_UUID_DECL(IUnknown, 0x, 0x, 0x, 0xc0,0x00, 0x00,0x00,0x00,0x00,0x00,0x46)")
- cpp_quote("HRESULT STDMETHODCALLTYPE IUnknown_QueryInterface_Proxy(IUnknown *This, REFIID riid, void **ppvObject);")
- cpp_quote("void __RPC_STUB IUnknown_QueryInterface_Stub(IRpcStubBuffer *This, IRpcChannelBuffer *_pRpcChannelBuffer, PRPC_MESSAGE _pRpcMessage, DWORD *_pdwStubPhase);")
- cpp_quote("ULONG STDMETHODCALLTYPE IUnknown_AddRef_Proxy(IUnknown *This);")
- cpp_quote("void __RPC_STUB IUnknown_AddRef_Stub(IRpcStubBuffer *This, IRpcChannelBuffer *_pRpcChannelBuffer, PRPC_MESSAGE _pRpcMessage, DWORD *_pdwStubPhase);")
- cpp_quote("ULONG STDMETHODCALLTYPE IUnknown_Release_Proxy(IUnknown *This);")
- cpp_quote("void __RPC_STUB IUnknown_Release_Stub(IRpcStubBuffer *This, IRpcChannelBuffer *_pRpcChannelBuffer, PRPC_MESSAGE _pRpcMessage, DWORD *_pdwStubPhase);")
cpp_quote("#else")
HRESULT QueryInterface ([in] REFIID riid,[out, iid_is (riid)] void **ppvObject);
ULONG AddRef ();
ULONG Release ();
}
cpp_quote("#endif")
+cpp_quote("HRESULT STDMETHODCALLTYPE IUnknown_QueryInterface_Proxy(IUnknown *This, REFIID riid, void **ppvObject);")
+cpp_quote("void __RPC_STUB IUnknown_QueryInterface_Stub(IRpcStubBuffer *This, IRpcChannelBuffer *_pRpcChannelBuffer, PRPC_MESSAGE _pRpcMessage, DWORD *_pdwStubPhase);")
+cpp_quote("ULONG STDMETHODCALLTYPE IUnknown_AddRef_Proxy(IUnknown *This);")
+cpp_quote("void __RPC_STUB IUnknown_AddRef_Stub(IRpcStubBuffer *This, IRpcChannelBuffer *_pRpcChannelBuffer, PRPC_MESSAGE _pRpcMessage, DWORD *_pdwStubPhase);")
+cpp_quote("ULONG STDMETHODCALLTYPE IUnknown_Release_Proxy(IUnknown *This);")
+cpp_quote("void __RPC_STUB IUnknown_Release_Stub(IRpcStubBuffer *This, IRpcChannelBuffer *_pRpcChannelBuffer, PRPC_MESSAGE _pRpcMessage, DWORD *_pdwStubPhase);")
cpp_quote("#endif")
cpp_quote("")
___
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] Fix uninitialized read in mingw-w64-tools/widl/src/typegen.c
Hi Raphael,
On 4/2/22 13:22, Raphael Isemann wrote:
The attached patch fixes an uninitialized read from memory in `union_memsize`.
The summary of how the bug happens is:
1. union_memsize gets called with a pointer to uninitialized `dummy`.
```
static unsigned int write_union_tfs(FILE *file, const attr_list_t *attrs,
type_t *type, unsigned int *tfsoff)
{
[...]
unsigned int dummy;
[...]
size = union_memsize(fields, );
```
2. `union_memsize` reads `pmaxa` (which points to dummy) to set the
initial value of align.
```
static unsigned int union_memsize(const var_list_t *fields, unsigned
int *pmaxa) {
unsigned int size, maxs = 0;
unsigned int align = *pmaxa;
const var_t *v;
if (fields) LIST_FOR_EACH_ENTRY( v, fields, const var_t, entry )
{
/* we could have an empty default field with NULL type */
if (v->declspec.type)
{
size = type_memsize_and_alignment(v->declspec.type, );
if (maxs < size) maxs = size;
if (*pmaxa < align) *pmaxa = align;
}
}
```
The rest of the code in `type_memsize_and_alignment` works with that
unitialized alignment value. If the uninitialized memory happens to
represent a larger uint than the actual max size of the union, then
that value is printed in the result.
Thanks for the patch. We import widl from Wine with as little changes as
possible. Please send the patch to Wine:
https://wiki.winehq.org/Submitting_Patches
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 comsupp library
On 3/17/22 09:56, Martin Storsjö wrote: However, autotools does some dubious choices here. If I'm configuring a cross compiler, and I do have x86_64-w64-mingw32-gcc but I don't have x86_64-w64-mingw32-g++ because I built only with --enable-languages=c, the configure script does this detection: checking for x86_64-w64-mingw32-g++... no checking for x86_64-w64-mingw32-c++... no checking for x86_64-w64-mingw32-gpp... no checking for x86_64-w64-mingw32-aCC... no checking for x86_64-w64-mingw32-CC... no checking for x86_64-w64-mingw32-cxx... no checking for x86_64-w64-mingw32-cc++... no checking for x86_64-w64-mingw32-cl.exe... no checking for x86_64-w64-mingw32-FCC... no checking for x86_64-w64-mingw32-KCC... no checking for x86_64-w64-mingw32-RCC... no checking for x86_64-w64-mingw32-xlC_r... no checking for x86_64-w64-mingw32-xlC... no checking for x86_64-w64-mingw32-clang++... no checking for g++... g++ configure: WARNING: using cross tools not prefixed with host triplet So instead of concluding that it didn't find any C++ compiler, it picks up the host (in my case, linux) C++ compiler instead. It gives a warning about it, but still proceeds, and any condition in the code would be enabled as it _did_ find a C++ commpiler. Building then later fails like this: g++ -DHAVE_CONFIG_H -I. -I.. -m64 "-I/opt/gcc-mingw/x86_64-w64-mingw32/include" -Wall -Wextra -Wformat -Wstrict-aliasing -Wshadow -Wpacked -Winline -g -O2 -MT libsrc/lib64_libcomsupp_a-comsupp.o -MD -MP -MF libsrc/.deps/lib64_libcomsupp_a-comsupp.Tpo -c -o libsrc/lib64_libcomsupp_a-comsupp.o `test -f 'libsrc/comsupp.cpp' || echo '../'`libsrc/comsupp.cpp g++: error: unrecognized command line option '-m64' Makefile:69208: recipe for target 'libsrc/lib64_libcomsupp_a-comsupp.o' failed This was on aarch64 linux, where GCC doesn't support the -m64 option. On x86_64 linux, where GCC does support the option, compiling of the file instead fails because it can't understand the Windows headers that are included when building it. Thus, TL;DR, technically this particular instance of C++ in mingw-w64-crt could be tolerable, but we must be very very careful about any addition of new C++ sources there. But the patch as is does indeed break setting up environments without a C++ compiler, which worked just fine before. Jacek, do you have any advice on autotools, for making it not accidentally pick up incorrect (host) compilers when the real intended one is missing? Yeah, this autotools behaviour looks buggy. I don't know how it's intended to be used, I'm CCing NightStrike hoping that he knows better what's going on. I can see some possible solution, but it would be nice to understand root of the problem: - We could use something like AC_COMPILE_IFELSE with input like: #ifndef __MINGW32__ #error ... #endif and skip C++ sources if that test fails. - We could just get rid of AC_PROG_CXX macro and instead check if $(CC) supports -xc++ option. If it does, use it for C++ sources, skip otherwise. - Use inline implementation. Those functions look easy enough for that. I guess the dependency is pulled by our comutil.h, or is it the application itself that calls them? 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 IVirtualDesktopManager interface
On 1/11/22 16:43, LIU Hao wrote: 在 2022-01-11 03:29, Tom Ritter 写道: I've changed BOOL -> WINBOOL (although this is the only use of WINBOOL in the file) -tom Thanks for the patch. I pushed it to master now. Use of `WINBOOL` instead of `BOOL` (which is a typedef for `bool` in objc) is mandatory for new stuff. There may be some left-behind `BOOL`s but no one has complained about them so far. While not very important in this case, we generally use BOOL in IDL files (where objc doesn't matter) and have -DBOOL=WINBOOL in widl invocation in Makefile.am so that generated headers use WINBOOL. 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] wtypes.h: replace #include <...> with #include "..." for rpc
On 1/14/22 02:29, LIU Hao wrote: 在 1/13/22 10:07 PM, Jonathan Marler 写道: Been 3 months since my last email, what's going on with this? On Tue, Oct 19, 2021 at 11:03 PM Jonathan Marler wrote: Jacek were you able to forward this discussion to Wine? If so do you have a link to that discussion? Thanks. This patch applies to a file that is directly copied from wine; any changes will be overwritten. Thus it will not be accepted. I'm adding wine as CC now. The original thread is located at https://sourceforge.net/p/mingw-w64/mailman/message/37341200/. Not really, the file is generated from wtypes.idl, which is not shared with Wine. It, however, requires widl change, and widl is shared with Wine. Jonathan, see bugs.winehq.org for Wine bug reports. 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] headers: Use oleacc.dll.tlb for oleacc typelib.
Signed-off-by: Jacek Caban
---
It's needed due to importlib handling changes in recent widl.
mingw-w64-headers/Makefile.am| 2 +-
mingw-w64-headers/tlb/{oleacc.idl => oleacc.dll.idl} | 0
2 files changed, 1 insertion(+), 1 deletion(-)
rename mingw-w64-headers/tlb/{oleacc.idl => oleacc.dll.idl} (100%)
diff --git a/mingw-w64-headers/Makefile.am b/mingw-w64-headers/Makefile.am
index 634fdcadb..0af3528e2 100644
--- a/mingw-w64-headers/Makefile.am
+++ b/mingw-w64-headers/Makefile.am
@@ -283,7 +283,7 @@ IDL_SRCS = \
include/xpsprint.idl
TLB_SRCS = \
- tlb/oleacc.idl \
+ tlb/oleacc.dll.idl \
tlb/stdole2.idl
BUILT_SOURCES = $(IDL_SRCS:.idl=.h) $(TLB_SRCS:.idl=.tlb)
diff --git a/mingw-w64-headers/tlb/oleacc.idl b/mingw-w64-headers/tlb/oleacc.dll.idl
similarity index 100%
rename from mingw-w64-headers/tlb/oleacc.idl
rename to mingw-w64-headers/tlb/oleacc.dll.idl
___
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] crt: Add fallback _vscprintf() implementation
On 1/16/22 23:51, Martin Storsjö wrote: On Sat, 15 Jan 2022, Pali Rohár wrote: In attachment are updated patches which adds these redirects and usage of F_NON_I386() macro. With these redirects it is possible to compile target mingw applications also with those gcc linker flags -Wl,--disable-auto-import -Wl,--disable-runtime-pseudo-reloc. Previously gcc really throw linker error about undefined symbols _vscrpintf. Thanks! These patches look acceptable to me. If Jacek doesn't mind, I'll go ahead and push them in a couple days. That's fine with 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] [PATCH] crt: Add fallback _vscprintf_emu code for __ms_vsnprintf()
On 12/29/21 16:52, Martin Storsjö wrote: On Wed, 29 Dec 2021, LIU Hao wrote: 在 2021-12-23 22:20, Pali Rohár 写道: Original MSVC 6.0 msvcrt.dll library does not provide _vscprintf() function. Therefore usage of snprintf() with this DLL library cause application crash. Add simple fallback implementation of _vscprintf() just for __ms_vsnprintf() to allow usage of snprintf() function also when using original msvcrt.dll library. This fallback implementation is static and not exported outside of vsnprintf.c source file. --- mingw-w64-crt/stdio/vsnprintf.c | 67 + 1 file changed, 67 insertions(+) I have an impression that we have not been supporting for VC6 since many years ago. All code targeting MSVCRT now requires Windows XP and the MSVCRT.DLL from it. While this is true in general, I'm not totally opposed to such a fairly nonintrusive workaround, if it makes things work in more cases with the original msvcrt.dll (and while we can't guarantee that it stays working). But I'm interested in hearing more opinions. Jacek? I'm not sure if we ever formalized treatment for old architectures, my impression is that we stopped carrying about them in reviews, but never cleaned up the tree so we never intentionally broke them. If we keep similar code anyway, a non-intrusive workaround seems fine. If we decided to use something like that, we should probably just hook _vscprintf like we do with other functions, through. However, cleaning the code from such workarounds seems tempting. I wonder if there is a real use case for this or is it just an experiment for fun? 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] widl: Fix importing tlb files from the mingw-w64 include dir
On 12/30/21 09:50, Martin Storsjö wrote: Import the latest version of widl from wine 7f95c692998daa83cbeffcbe261ebbff80af54a8 (wine-7.0-rc3-17-g7f95c692998). This fixes a regression in widl in the mingw-w64 setup after 826215b4e0b54fe459bce203024fe50ec883cad8, which imported a newer version of wine from upstream, which regressed importing tlb files in the mingw-w64 directory layout. Signed-off-by: Martin Storsjö Looks good to me, thanks for fixing 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] [PATCH 3/3] winuser.h: Add PW_RENDERFULLCONTENT define.
On 11/1/21 4:20 PM, LIU Hao wrote: 在 2021-10-30 23:18, Tom Ritter 写道: Hi, I wanted to follow up on this patch series and ask if they could be landed? Thanks. Perhaps Jacek has been busy with other stuff. I have pushed these three patches to master for now. I just came back from vacations and didn't get to that yet. Thanks for pushing it. 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 2/3] ksuser: Add KSCATEGORY_VIDEO_CAMERA declaration.
Signed-off-by: Jacek Caban --- mingw-w64-crt/libsrc/ksuser.c | 1 + 1 file changed, 1 insertion(+) diff --git a/mingw-w64-crt/libsrc/ksuser.c b/mingw-w64-crt/libsrc/ksuser.c index 3cc7f1e33..b5e37fa7c 100644 --- a/mingw-w64-crt/libsrc/ksuser.c +++ b/mingw-w64-crt/libsrc/ksuser.c @@ -129,6 +129,7 @@ DEFINE_GUID(KSCATEGORY_TVAUDIO,0xa799a802,0xa46d,0x11d0,0xa1,0x8c,0,0xa0,0x24,0x DEFINE_GUID(KSCATEGORY_TVTUNER,0xa799a800,0xa46d,0x11d0,0xa1,0x8c,0,0xa0,0x24,0x1,0xdc,0xd4); DEFINE_GUID(KSCATEGORY_VBICODEC,0x7dad660,0x22f1,0x11d1,0xa9,0xf4,0,0xc0,0x4f,0xbb,0xde,0x8f); DEFINE_GUID(KSCATEGORY_VIDEO,0x6994ad05,0x93ef,0x11d0,0xa3,0xcc,0,0xa0,0xc9,0x22,0x31,0x96); +DEFINE_GUID(KSCATEGORY_VIDEO_CAMERA,0xe5323777,0xf976,0x4f5b,0x9b,0x55,0xb9,0x46,0x99,0xc4,0x6e,0x44); DEFINE_GUID(KSCATEGORY_VIRTUAL,0x3503eac4,0x1f26,0x11d1,0x8a,0xb0,0,0xa0,0xc9,0x22,0x31,0x96); DEFINE_GUID(KSCATEGORY_VPMUX,0xa799a803,0xa46d,0x11d0,0xa1,0x8c,0,0xa0,0x24,0x1,0xdc,0xd4); DEFINE_GUID(KSCATEGORY_WDMAUD,0x3e227e76,0x690d,0x11d2,0x81,0x61,0,0,0xf8,0x77,0x5b,0xf1); ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] [PATCH 3/3] winuser.h: Add PW_RENDERFULLCONTENT define.
Signed-off-by: Jacek Caban
---
mingw-w64-headers/include/winuser.h | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/mingw-w64-headers/include/winuser.h b/mingw-w64-headers/include/winuser.h
index 01f2a5be4..7252a53ea 100644
--- a/mingw-w64-headers/include/winuser.h
+++ b/mingw-w64-headers/include/winuser.h
@@ -2241,7 +2241,10 @@ extern "C" {
#if WINAPI_FAMILY_PARTITION (WINAPI_PARTITION_DESKTOP)
WINUSERAPI WINBOOL WINAPI GetLayeredWindowAttributes (HWND hwnd, COLORREF *pcrKey, BYTE *pbAlpha, DWORD *pdwFlags);
-#define PW_CLIENTONLY 0x0001
+#define PW_CLIENTONLY 0x0001
+#if _WIN32_WINNT >= 0x0603
+#define PW_RENDERFULLCONTENT 0x0002
+#endif
WINUSERAPI WINBOOL WINAPI PrintWindow (HWND hwnd, HDC hdcBlt, UINT nFlags);
WINUSERAPI WINBOOL WINAPI SetLayeredWindowAttributes (HWND hwnd, COLORREF crKey, BYTE bAlpha, DWORD dwFlags);
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] [PATCH 1/3] crt: Include windowscodecs.c in libuuid.a.
Signed-off-by: Jacek Caban --- That seems to match recent Windows SDK. mingw-w64-crt/Makefile.am | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/mingw-w64-crt/Makefile.am b/mingw-w64-crt/Makefile.am index 78d9a0a59..e889185a0 100644 --- a/mingw-w64-crt/Makefile.am +++ b/mingw-w64-crt/Makefile.am @@ -145,7 +145,8 @@ src_libuuid=\ libsrc/ntddser-uuid.c libsrc/ntddstor-uuid.clibsrc/ntddvdeo-uuid.clibsrc/oaidl-uuid.c libsrc/objidl-uuid.c \ libsrc/objsafe-uuid.c libsrc/ocidl-uuid.c libsrc/oleacc-uuid.c libsrc/olectlid-uuid.c libsrc/oleidl-uuid.c \ libsrc/power-uuid.c libsrc/powrprof-uuid.clibsrc/uianimation-uuid.c libsrc/usbcamdi-uuid.c libsrc/usbiodef-uuid.c \ - libsrc/uuid.c libsrc/vds-uuid.c libsrc/virtdisk-uuid.clibsrc/wia-uuid.c + libsrc/uuid.c libsrc/vds-uuid.c libsrc/virtdisk-uuid.clibsrc/wia-uuid.c \ + libsrc/windowscodecs.c src_libws2_32=libsrc/ws2_32.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] wtypes.h: replace #include <...> with #include "..." for rpc
On 9/5/21 4:54 PM, LIU Hao wrote: 在 2021-09-04 23:53, JonY via Mingw-w64-public 写道: I am OK with updating them to use double quotes but have no strong preference anyway since it has been using angular brackets for a long time. So this change is okay, but... I have noticed that wtypes.h is generated from wtypes.idl, which contains no reference to or . I don't know where those includes come from. Jacek, do you have any ideas? They come from widl, so if we want this change, then widl needs to be changed instead. It looks like the reverse was done in the past: https://source.winehq.org/git/wine.git/commitdiff/0bde2bbe010c68a54f8928469e89637a2322ae44 I don't know what was the reasoning there, it seems fine to change it back. Thanks, Jacek ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] wtypes.h: replace #include <...> with #include "..." for rpc
Hi Jonathan, On 9/3/21 11:48 PM, Jonathan Marler wrote: Been another 4 days, anyone able to bring this patch in or review? Your patch never arrived to the mailing list, it looks like the attachment is missing. Jacek ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] headers: Import propvarutil.h from wine
On 7/20/21 4:58 PM, John Warburton wrote: On Tue, 20 Jul 2021 at 15:09, Biswapriyo Nath wrote: Apology for my mistake. It has been fixed today in wine by Jacek Caban in this commit[1]. Thank you for checking this. I am testing a build now. Whoops. I forgot. That's Wine -- will wait for mingw-w64 to be altered. I just pushed an update. 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] Discussion: Need new function declarations in propvarutil.h from wine
On 7/12/21 9:15 AM, LIU Hao wrote: 在 7/12/21 2:44 PM, Biswapriyo Nath 写道: Would you like to upstream that change? I am not the author of that commit and don't know why it was added. qt6-multimedia compiles fine without that NTSTATUS re-definition. FWIW, that typedef thing is a declaration, rather than a definition. This means that duplicates of such typedefs are allowed as long as they don't disagree with each other. I think the `#if...#endif` check may be removed. Sure, so we don't need to worry about syncing guard names, I sent a patch to Wine: https://source.winehq.org/patches/data/209719 There is another problem introduced by: https://source.winehq.org/git/wine.git/commitdiff/4f52e32205fc3cc3f09adf6d7ff961c36e3b1f4d I sent a fix: https://source.winehq.org/patches/data/209718 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] Discussion: Need new function declarations in propvarutil.h from wine
On 7/11/21 3:26 PM, Biswapriyo Nath wrote: Option 1: Import propvarutil.h from wine. But that reverts this commit propvarutil.h: Added NTSTATUS declaration (d603db2). Before that commit propvarutil.h was imported from wine. I have compiled qt6-multimedia without that NTSTATUS declaration. Option 2: Add new function declarations manually. So, which one will be better? Option 3: upsteram d603db2 to Wine and then import the header to mingw-w64. Wine uses a different guard macro, so this will need to be synced 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] crt: Don't initialize lconv to unsigned char mode
On 6/11/21 3:51 AM, Liu Hao wrote: 在 6/11/21 4:09 AM, Martin Storsjö 写道: Since the initial commit of mingw-w64, there's a call (in a constructor in crt/charmax.c, pulled in via the mingw_initcharmax variable) to __lconv_init(), which reconfigures the CRT's lconv info to unsigned char mode - but there's no explanation for why this is the case. The fact that mingw-w64 initializes lconv info this way breaks a test in llvm's libc++ (where it expects lconv's frac_digits to be intialized to CHAR_MAX, not UCHAR_MAX). This also differs to how MSVC environments behave, where they are initialized to CHAR_MAX. So unless there's a clear known reason why we'd initialize it to unsigned char mode, revert to the same behaviour as MSVC has. Signed-off-by: Martin Storsjö --- mingw-w64-crt/crt/crtexe.c | 2 -- 1 file changed, 2 deletions(-) This patch looks good to me. Looks good to me as well. I'm not sure if we want to keep charmax.c at all, or change default _charmax value, but it doesn't need to block this patch. 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] include/intrin-impl: Don't define `__cpuidex` for GCC 11
On 20/05/2021 17:46, Liu Hao wrote: 在 2021-05-20 22:40, Jacek Caban 写道: We could #undef __cpuid just after including cpuid.h. Updated patch is attached. The whole thing is really a hack, but I don't see a better solution, so it looks fine 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] [PATCH] include/intrin-impl: Don't define `__cpuidex` for GCC 11
On 5/20/21 4:37 PM, Liu Hao wrote: 在 2021-05-20 22:29, Jacek Caban 写道: On 5/20/21 4:21 PM, Liu Hao wrote: +#if (!defined(__GNUC__) || __GNUC__ < 11) __MACHINEI(void __cpuid(int a[4],int b)) +#endif __cpuid is a macro in both older GCCs and clang, so it will probably not work there. It's also present in intrin-impl.h. So what should we do? Can we just comment it out? We could #undef __cpuid just after including cpuid.h. 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] include/intrin-impl: Don't define `__cpuidex` for GCC 11
On 5/20/21 4:21 PM, Liu Hao wrote: +#if (!defined(__GNUC__) || __GNUC__ < 11) __MACHINEI(void __cpuid(int a[4],int b)) +#endif __cpuid is a macro in both older GCCs and clang, so it will probably not work there. It's also present in intrin-impl.h. 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] include/intrin-impl: Don't define `__cpuidex` for GCC 11
Hi Liu, On 5/10/21 6:45 PM, Liu Hao wrote: Subject: [PATCH] include/intrin-impl: Don't define `__cpuidex` for GCC 11 GCC 11 has this as a static inline function without any indicative macros. Reference:https://github.com/gcc-mirror/gcc/blob/23855a176609fe8dda6abaf2b21846b4517966eb/gcc/config/i386/cpuid.h#L333 As far as I can see, cpuid.h is not included by any other header shipped with GCC. It means that with your changes, users will would need to start including it themselves in addition to intrin.h. For similar cases with other *intrin.h headers provided by GCC, we simply include them from intrin.h to avoid collisions. cpuid.h is risky in this regard, because it seems to provide way more than we want. But maybe that's fine... 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] __CRT_UUID_DECL in namespace causes error
On 5/14/21 11:20 AM, Biswapriyo Nath wrote: If an interface declaration is moved inside a namespace __CRT_UUID_DECL produces error. The error is: explicit specialization of 'template const GUID& __mingw_uuidof()' outside its namespace must use a nested-name-specifier [-fpermissive]. A simple reproducible code is attached (test.cpp). The same thing happen with qtmultimedia/src/plugins/wmf/player/mfvideorenderercontrol.cpp file of branch 5.15.2. It looks to me like something that should be fixed in Qt by putting the macro in a global namespace. widl already does that for interfaces declared in IDL files. There is little we can do on mingw-w64 side (unless I'm missing something). Obviously ideal solution would be to implement proper support for __uuidof in GCC... On semi-related note, the definition was changed on Wine and it may be interesting to get ported to mingw-w64: https://source.winehq.org/git/wine.git/blob/HEAD:/include/guiddef.h#l53 https://source.winehq.org/git/wine.git/commitdiff/51b75e9a534d8c6021bbcc71889e3c154f0f84ea 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] wine FTBFS with mingw64 gcc 11: undefined reference to `sincos'
On 15/05/2021 04:24, lhmouse wrote: 在 5/15/21 1:27 AM, Jacek Caban 写道: I think that the decision was unfortunate on GCC side, but there is little we can do. We will probably need to provide it in msvcrt importlibs. Please try the attached patch, it should help. Doesn't GCC transform such pair of calls to `sincos()` again and result in an infinite recursion? The patched file is built with -fno-builtin, so it should be fine. 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] wine FTBFS with mingw64 gcc 11: undefined reference to `sincos'
Hi Alex,
On 5/14/21 3:01 AM, Alex Xu (Hello71) wrote:
Hi,
I tried building wine 6.8 with mingw. All fine, just one problem, it
reports error "undefined reference to `sincos'". Why, you may ask, since
wine never calls sincos function? Well, it seems to be because mingw gcc
11 enables sincos optimization: [0]. But, wine uses -nodefaultlibs,
intending to provide libc functions with msvcrt; however, wine msvcrt
doesn't implement any sincos. So, there is a mismatch: gcc accepts mingw
claim to implement sincos (ok since mingwex implements it), then
generates call to sincos, then fails at link time (because msvcrt does
not implement it).
After adding -fno-builtin-{sin,cos}{,f} to CFLAGS, wine compiled and ran
OK.
This issue seems to be worked around for winelib builds by adding
-fno-builtin, so that gcc will not generate sincos (or most other
problematic functions).
I think this issue could be worked around by adding those -fno-builtin-*
flags for mingw builds. However, I think the sin/cos->sincos
optimization is a good one, so maybe we could instead add sincos
forwarder in msvcrt (calling sin+cos separately in case sincos is not
implemented in libc?).
CCed mingw-w64-public@lists.sourceforge.net due to potential relevance
and felixonm...@archlinux.org due to maintaining wine and mingw-gcc on
Arch. You may need to subscribe in order to reply all. I look forward to
hearing your thoughts.
I think that the decision was unfortunate on GCC side, but there is
little we can do. We will probably need to provide it in msvcrt
importlibs. Please try the attached patch, it should help.
Thanks,
Jacek
diff --git a/dlls/msvcrt/mathf.c b/dlls/msvcrt/mathf.c
index 4038bdb4cf7..3cd5377f1e4 100644
--- a/dlls/msvcrt/mathf.c
+++ b/dlls/msvcrt/mathf.c
@@ -67,3 +67,15 @@ float exp2f(float x) { return powf(2.0f, x); }
__ASM_GLOBAL_IMPORT(exp2)
__ASM_GLOBAL_IMPORT(exp2f)
#endif
+
+void sincos(double x, double *s, double *c)
+{
+*s = sin(x);
+*c = cos(x);
+}
+
+void sincosf(float x, float *s, float *c)
+{
+*s = sinf(x);
+*c = cosf(x);
+}
___
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: Increase precision of gettimeofday() if possible.
On 5/3/21 2:52 PM, Martin Storsjö wrote: On Mon, 3 May 2021, Christian Franke wrote: Would plain '... = 0' without cast also work ? IIRC it should since C89 :-) That doesn't work either - clang seems to consider the cast (either implicit or explicit) between a integer or pointer-to-integer and a pointer-to-function as something which isn't a compile time constant, in this context... Alternative: Leave '/* = 0 */' only as a comment. There is no need to set a static variable to 0. That would work. But the overall question remains - we don't really require a C11 compiler for this yet, so use of that kind of atomics is a bit odd overall. If we use it, I think we should have to bump the requirement by explicitly building with -std=gnu11 or something like that. If we go that way, I think we should use C11 atomics for all of it, i.e. replace InterlockedCompareExchangePointer with a C11 equivalent. Or go the other way, and use Interlocked* for both reads and updates of it (and then the variable itself doesn't need to be declared _Atomic, afaik). Or just skip that aspect altogether and just blindly update the pointer variable; that's what's done in every existing case of GetProcAddress lazy loading in mingw-w64-crt. I'd say that we should skip it altogether. Atomic operations seem totally redundant in this case. What would it protect from? It won't prevent multiple GetProcAddress calls - for that we'd need a critical section. Since GetProcAddress will always return the same pointer, setting the static pointer multiple times is harmless. 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 symbols for POSIX time functions
On 31.03.2021 15:12, Martin Storsjö wrote:
On Wed, 31 Mar 2021, Liu Hao wrote:
在 2021/3/31 下午7:46, Martin Storsjö 写道:
Hmm, if MSVC defaults to a 64 bit time_t in 32 bit mode these days,
I think we should too, for UCRT. (Technically I guess it's an ABI
break, but I'd be quite comfortable doing it, while I'd be less
comfortable changing any defaults for msvcrt.dll targets.)
It is not only 'these days'. Even with VS2013, when CL.EXE is invoked
from command line, the default size of `time_t` will be 8 bytes, no
matter whether to target x86 or x64, unless `_USE_32BIT_TIME_T` is
defined, in which case it is 4 bytes.
```c
/* Run these commands in 'VS2013 x86 Native Tools Command Prompt':
*
* cl test.c && test.exe
* cl /D_USE_32BIT_TIME_T test.c && test.exe
**/
#include
#include
int main(void)
{
printf("sizeof(time_t) = %d\n", (int)sizeof(time_t));
}
```
Fair point, it's probably been doing the sensible thing for quite a
while now already. But anyway, we probably shouldn't be changing the
defaults for msvcrt.dll targets, but for UCRT I think we are much more
excused to be changing things.
Agreed, I think that it would be better to use 64-bit time_t by default
for UCRT.
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: Update the layout of struct _iobuf to match the layout used in UCRT
On 26/03/2021 12:22, Martin Storsjö wrote: As there's no code that could be using the new UCRT spelling using any public headers, there's nothing we can try to remain compatible with in that case, so we'd only be setting new predecent (i.e. if building with mingw headers, and iff targeting UCRT, then access the field with a different name). I.e., I'm a bit hesitant about whether we should be doing this at all, or if we should follow suit and make it a similar struct containing only the first member instead? In my opinion it was the right call by Microsoft to do that, so it would be nice to follow. 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 08/20] headers: move EventHandler delegate in windows.foundation.idl
Hi Steve, On 09.03.2021 15:03, Steve Lhomme wrote: .../include/windows.foundation.collections.idl| 6 -- mingw-w64-headers/include/windows.foundation.idl | 8 2 files changed, 8 insertions(+), 6 deletions(-) windows.foundation.collections.idl is imported from Wine, please send changes there. I was hoping to import windows.foundation.idl as well once Wine's version is in good enough shape. 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 deprecated `_{str, wcs}lwrt` aliases in DEF
On 05.02.2021 13:14, Liu Hao wrote: 在 2021-02-05 15:16, JonY via Mingw-w64-public 写道: Your attached patch seems fine to me, please go ahead and push. Thanks, pushed. What about the others? They all look 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] [PATCH] headers: Import wmp.idl from wine.
Hi, Looks good to me, I pushed it. 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] IExtractIcon missing functions
On 11.01.2021 18:37, Biswapriyo Nath wrote: Hmmm why aren't those IDLs imported from Wine? 1. Huge confusion. IExtractIcon is in -- shlobj_core.h in WinSDK, shlobjidl.idl in wine, shlobj.h in mingw-w64. 2. Files differ largely between mingw-w64 and wine. We still may import them, it's just more work. We could make it more compatible with Windows SDK in Wine if needed. We'd need also to make sure that by importing we will not lose any declarations and then we can import them. BTW, it's shobjidl.idl (without 'l') and it exists in Windows SDK. 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: Use Windows 10 as default _WIN32_WINNT value.
Hi Martin, Sorry for the delay. On 04.01.2021 21:16, Martin Storsjö wrote: Hi, On Mon, 4 Jan 2021, Jacek Caban wrote: FWIW, I think that the attached patch should do the right thing on VLC (but I don't really have setup to test it). Thanks, looks like that could be enough - I'll try to get time to think through and test the potential combinations. A different case that came to mind now is ffmpeg; http://git.videolan.org/?p=ffmpeg.git;a=blob;f=configure;h=900505756bf6fb734708da6278689037157fc53a;hb=0cd8769207f1a89fc2236aab9da1c77f5a0b490a#l5628 I guess the fix here would be to do the check without including a header first, to check whether it was defined in cflags. Then again, I just checked building with -D_WIN32_WINNT=0xA00, and the binary started on Vista, so there doesn't seem to be any configure tests for features above that anyway. ffmpeg use seems fine to me. They just make sure that it's high enough to have required declarations available. It doesn't seem to make any runtime decision based on _WIN32_WINNT value. It sounds lime msys2 will not be affected. I don't mind waiting with committing this patch if helps. I only think that it would be good to commit relatively early in release cycle so that we have time to address feedback. At this point, I don't think there's need to wait any more; it'd better to get it out there and see what it breaks, if anything, sooner rather than later. (And my setups already override it to win7 anyway, but I guess I could consider leaving it to the default if it's higher.) Sounds good to me, I pushed the commit. I also faintly remember somebody suggesting that we'd formally drop support for XP altogether. FWIW, that sounds about right to me, but I didn't want to make this change about dropping XP support. I guess that what we're missing is some form of discussion and formalizing it, if that's the consensus. Yeah, that's probably a separate discussion. And before doing it, I guess we should quantify what we actually gain from it, instead of just doing it for the sake of doing it. Being able to rely on more features in msvcrt.dll (for setups that use it) probably would be one thing. I'd be tempted to consider defaulting to UCRT, but I realize that it has serious compatibility implications. If we decided to do it, it would make msvcrt.dll setup much less important (and maybe even a way to keep optional compatibility with older Windows). It seems to me that llvm-mingw is successful defaulting to UCRT, do you think it makes sense for upstream default? Well, that comes with a bit bigger incompatibility, as it breaks most existing precompiled static libraries. In a sense, that's not new. We already caused them to be incompatible many times while changing crt. Of course we try to keep compatibility as much as possible, but it's often needed if we want to progress. An example of such changes is moving things to libmsvcrt.a to be able to better support both ucrt and classic msvcrt.dll. We already did it, so it's already true that if you mix static libraries with random toolchain versions, you may run into a problem. I'm not aware of any large scale practical problems caused by this (but I may be missing something). Of course a switch to ucrt is an order of magnitude more impactful to static libraries, but my feeling is that ecosystem can deal with such changes. I may be too optimistic about this, through. That's easier for llvm-mingw anyway, as it's mostly incompatible (due to libc++) - so it's mostly convenient where you build everything from scratch everytime. But even there, I've now started providing msvcrt.dll based builds (for people who want to target older versions where UCRT isn't guaranteed to be available, and for compatibility with precompiled non-C++ static libraries). I see, so there is still enough interest in that. It also means that it would be good to not break it on mingw-w64 crt side. I guess that keeping msvcrt.dll based crt in its current form is easy. If we want to use newer features in common (mingwex) code, we can move even more of it to lib*cr* libraries, keep old behavior in old libraries and use code depending on newer Windows versions only in ucrt. I can imagine going as far as moving entire entry point implementations, if it comes to this. This way old platforms could miss new features, but would not regress. AFAIK msys2 are considering switching to this as well, but it's in one sense a much bigger break. It will be interesting to see how it goes. 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: Use Windows 10 as default _WIN32_WINNT value.
On 31.12.2020 21:31, Martin Storsjö wrote:
On Thu, 31 Dec 2020, Jacek Caban wrote:
Yes, but the critical part is the very first sentence, which says
that 'you can specify which versions of Windows your code can run
on.'. Note the difference between *can* and *need*. When using
mingw-w64 with its defaults, you essentially *need* to do that if
you're working on a modern application. That article is about
changing the value, not about the meaning of its default value. The
current difference between 'can' and 'need' comes from toolchain
defaults and all we need to do to be precisely compatible with
mentioned documentation is to change the default to win10, like
authors of this documentation did in their SDK.
Fair enough, yes, that's a correct distinction to make here I guess.
I guess that was the core part of my doubts regarding this, so with
that cleared, I won't object to this change.
I still think there's a risk that it'll break (or more subtly, affect)
a handful of projects (I need to revisit VLC's configure, for
instance), so some general headsup to e.g. the msys2 project probably
is warranted though.
FWIW, I think that the attached patch should do the right thing on VLC
(but I don't really have setup to test it). If I'd choose the way to
handle it myself, I'd set it always to win10 and have separated macro
like VLC_MIN_WIN32 which I'd use internally, but current use should be
perfectly fine with something like the patch.
It sounds lime msys2 will not be affected. I don't mind waiting with
committing this patch if helps. I only think that it would be good to
commit relatively early in release cycle so that we have time to address
feedback.
I also faintly remember somebody suggesting that we'd formally drop
support for XP altogether.
FWIW, that sounds about right to me, but I didn't want to make this
change about dropping XP support. I guess that what we're missing is
some form of discussion and formalizing it, if that's the consensus.
Yeah, that's probably a separate discussion. And before doing it, I
guess we should quantify what we actually gain from it, instead of
just doing it for the sake of doing it. Being able to rely on more
features in msvcrt.dll (for setups that use it) probably would be one
thing.
I'd be tempted to consider defaulting to UCRT, but I realize that it has
serious compatibility implications. If we decided to do it, it would
make msvcrt.dll setup much less important (and maybe even a way to keep
optional compatibility with older Windows). It seems to me that
llvm-mingw is successful defaulting to UCRT, do you think it makes sense
for upstream default?
Thanks,
Jacek
diff --git a/configure.ac b/configure.ac
index 96e47b1969..45b26bf8f7 100644
--- a/configure.ac
+++ b/configure.ac
@@ -264,11 +264,6 @@ case "${host_os}" in
AC_PREPROC_IFELSE([AC_LANG_PROGRAM(
[[#ifdef _WIN32_WINNT
# error _WIN32_WINNT already defined
- #else
- # include
- # if defined(_WIN32_WINNT) && _WIN32_WINNT >= 0x0601
- # error _WIN32_WINNT toolchain default high enough
- # endif
#endif
]],[[;]])
],[
___
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 28.12.2020 23:23, Martin Storsjö wrote: On Mon, 28 Dec 2020, Jacek Caban wrote: As long as the application does not use new APIs, its compatibility with older Windows will not change. And this bit: This value is commonly mistaken with 'minimum version supported in runtime', which is simply not the case. It's only a version that headers will provide declarations for. https://docs.microsoft.com/en-us/cpp/porting/modifying-winver-and-win32-winnt says The preprocessor macros WINVER and _WIN32_WINNT specify the minimum operating system version your code supports. Yes, but the critical part is the very first sentence, which says that 'you can specify which versions of Windows your code can run on.'. Note the difference between *can* and *need*. When using mingw-w64 with its defaults, you essentially *need* to do that if you're working on a modern application. That article is about changing the value, not about the meaning of its default value. The current difference between 'can' and 'need' comes from toolchain defaults and all we need to do to be precisely compatible with mentioned documentation is to change the default to win10, like authors of this documentation did in their SDK. If users still want headers to not provide Win10-only declarations, they may just set _WIN32_WINNT explicitly in build system to the exact version they want. If packagers prefer it the old way, they can use the configure stitch for that. Yeah, it's good that we're able to override the default - I think I'd still keep doing that. But I think there's at least some amount of projects (mingw centric projects primarily, as the default in MSVC is different) that expect and rely on the current norm of it being set to the minimum. Those are bugs in these projects. I'm not keen to break them, but I also don't think that we should keep current situation forever. I'd like users, who just installed a default mingw-w64, to be able to just #include and have the best of mingw-w64 available. Right now, when they try to use any recent API (as in younger than 19 years), they have to learn about _WIN32_WINNT and mess with it. In my opinion, they should not be required to do that. (Once they have some specific expectations about OS version, they may still want/need to do that, but mistakes of unrelated projects should not be among reasons to mess with _WIN32_WINNT). That sounds like a sensible goal to have - but I'm a little undecided about the practicalities. Then again, I can agree with the argument that projects that are built for distribution across older versions maybe should take care to specifically set the define themselves anyway. Regarding the current archaic default, an alternative path (that doesn't take us all the way, but at least a bit on the way) would be to bump it to Win7. I think that it's better than nothing, but it would only move the problem. It also rises more questions like why not win8? When will we rise it again? Will we wait until win7 becomes 19 years old? I think that those questions are better answered individually by projects themselves, we can't make a single choice good for all of them. I also faintly remember somebody suggesting that we'd formally drop support for XP altogether. FWIW, that sounds about right to me, but I didn't want to make this change about dropping XP support. I guess that what we're missing is some form of discussion and formalizing it, if that's the consensus. 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: Use Windows 10 as default _WIN32_WINNT value.
On 28.12.2020 03:39, Liu Hao wrote: 在 2020/12/27 上午5:44, Martin Storsjö 写道: I'm not entierely sure I agree with this - I think different ecosystems have different expectations here. (It'd be interesting to e.g. rebuild all of msys2's mingw package repository with such headers, and see how many of them fail to run on the previous minimum version.) If users still want headers to not provide Win10-only declarations, they may just set _WIN32_WINNT explicitly in build system to the exact version they want. If packagers prefer it the old way, they can use the configure stitch for that. Yeah, it's good that we're able to override the default - I think I'd still keep doing that. But I think there's at least some amount of projects (mingw centric projects primarily, as the default in MSVC is different) that expect and rely on the current norm of it being set to the minimum. I have an impression that all projects should have defined `_WIN32_WINNT` in a similar way to how people work with feature test macros on Linux (the GNU C++ compiler on Linux defines `_GNU_SOURCE` but I think it's bad practice). The default value of `_WIN32_WINNT` doesn't matter in a sense. (And if we should catch with everything by default, why not just define it to `0x`?) I think that there are no plans for post-Windows 10 versions releases at the moment, so win10 should work just as well for foreseeable future without introducing a new value. There is also NTDDI_VERSION, which specifies win10 variant and we currently default it to 0. Jacek ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
