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
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
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
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
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
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
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 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
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
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
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
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
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
___
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
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.
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
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
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
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
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,
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
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
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
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:
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
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
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
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-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
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
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
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
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
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
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 |
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
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
Pushed, thanks.
Jacek
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
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 s
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
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
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
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
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
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
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.
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
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
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
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 complic
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
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
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
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
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
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
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.
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
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
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
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
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
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
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
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,
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
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
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
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/
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
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
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
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
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
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
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
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
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
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
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,
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
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
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
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 w
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
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.
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
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
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
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
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
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
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
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
___
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
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
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
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
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
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
1 - 100 of 813 matches
Mail list logo
