[Mingw-w64-public] [Project News|New Builds]

Hi, The new builds of MinGW-W64 based on GCC-7.2.0 as 'rev1' was uploaded. MinGW-w64 v5.x branch was used. 32-bit: posix-sjlj: https://sf.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/mingw-builds/7.2.0/threads-posix/sjlj/i686-7.2.0-release-posix-sjlj-rt_v5-rev

[Mingw-w64-public] [Project News|New Builds]

Hi, The new builds of MinGW-W64 based on GCC-4.9.4 as 'rev0' was uploaded. MinGW-w64 v5.x branch was used. 32-bit: posix-sjlj: https://sf.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/mingw-builds/4.9.4/threads-posix/sjlj/i686-4.9.4-release-posix-sjlj-rt_v5-r

Re: [Mingw-w64-public] swscanf() crashes if __USE_MINGW_ANSI_STDIO is defined

On 14 November 2017 at 11:40, Liu Hao wrote: > On 2017/11/14 9:58, Liu Hao wrote: >> On 2017/11/13 11:11, David Lee wrote: >>> Built and tested a cross compiler (i686-w64-mingw32-gcc 6.4.0) on >>> debian stretch with master mingw-w64. Same crash. >>> >> Yeah I just updated MSYS2's repos and observ

[Mingw-w64-public] [PATCH] stdio/mingw_wvfscanf.c: Fix segmentation fault when a char or, string format (without malloc option) is used, like, 72d60c1a06490ec5937e6c620956b167bf0bf329.

This patches addresses the issue in . The C99 standard treats %s, %c, %ls and %lc identically in *scanf and w*scanf, hence this patch is merely copy-pasting from 72d60c1a06490ec5937e6c620956b167bf0bf329. With this patch the problem

[Mingw-w64-public] [PATCH] crt: Add an alias from _ftime to _ftime32 for ucrtbase

For 32 bit platforms, the "ftime" function ends up as a reference to _ftime. We could do this in the headers, but MSVC has got a similar linker alias, so this solution should also cover cases when a caller ends up with a reference to _ftime via some other means. Signed-off-by: Martin Storsjö ---

Re: [Mingw-w64-public] [PATCH 3/3] crt: Map _find{first, next} to _find{first, next}32 on ucrtbase 32 bit x86

On Tue, 14 Nov 2017, Martin Storsjö wrote: On Tue, 14 Nov 2017, Martin Storsjö wrote: On Mon, 13 Nov 2017, Martin Storsjö wrote: This is only to match what we do for msvcrt; the function name with a -32 suffix is the canonial that the headers should end up using. Signed-off-by: Martin Stors

Re: [Mingw-w64-public] [PATCH] headers: Use _ftime32 instead of _ftime on ucrtbase

On Mon, 13 Nov 2017, Martin Storsjö wrote: Signed-off-by: Martin Storsjö --- mingw-w64-headers/crt/sys/timeb.h | 3 +++ 1 file changed, 3 insertions(+) diff --git a/mingw-w64-headers/crt/sys/timeb.h b/mingw-w64-headers/crt/sys/timeb.h index c92c8e0..ee947f0 100644 --- a/mingw-w64-headers/crt/s

Re: [Mingw-w64-public] [PATCH 3/3] crt: Map _find{first, next} to _find{first, next}32 on ucrtbase 32 bit x86

On Tue, 14 Nov 2017, Martin Storsjö wrote: On Mon, 13 Nov 2017, Martin Storsjö wrote: This is only to match what we do for msvcrt; the function name with a -32 suffix is the canonial that the headers should end up using. Signed-off-by: Martin Storsjö --- mingw-w64-crt/lib-common/ucrtbase.def

Re: [Mingw-w64-public] [PATCH 3/3] crt: Map _find{first, next} to _find{first, next}32 on ucrtbase 32 bit x86

On Mon, 13 Nov 2017, Martin Storsjö wrote: This is only to match what we do for msvcrt; the function name with a -32 suffix is the canonial that the headers should end up using. Signed-off-by: Martin Storsjö --- mingw-w64-crt/lib-common/ucrtbase.def.in | 2 ++ 1 file changed, 2 insertions(+) d

Re: [Mingw-w64-public] Importing other IDLs from wine

On 14.11.2017 11:29, Shinchiro Shinchiro wrote: > So how about the status of this issue? It still needs debugging, AFAIK. Cheers, Jacek -- Check out the vibrant tech community on one of the world's most engaging tech sit

Re: [Mingw-w64-public] Importing other IDLs from wine

So how about the status of this issue? Just to add that, after replacing all IDLs in mingw-w64-headers\include with wine's one, there's another necessary IDL's in order to compile the dxgi1_6.idl xmldso.idl xmldom.idl -- C