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

2017-11-14 Thread niXman 

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-rev1.7z
(VirusTotal report: 
https://www.virustotal.com/#/file/cc2a13fa48a5c56893aa04d203744ea98dc4209fcd99c8f22828cc371d89a0e1/detection)


posix-dwarf: 
https://sf.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/mingw-builds/7.2.0/threads-posix/dwarf/i686-7.2.0-release-posix-dwarf-rt_v5-rev1.7z
(VirusTotal report: 
https://www.virustotal.com/#/file/8451a013ce317c72edde4c65932d6770dd98910a27714527ac27dc76bd3123f1/detection)


win32-sjlj: 
https://sf.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/mingw-builds/7.2.0/threads-win32/sjlj/i686-7.2.0-release-win32-sjlj-rt_v5-rev1.7z
(VirusTotal report: 
https://www.virustotal.com/#/file/08b0294a84bddb4476e85f7c3f065a34a457f825b1580f384933ced16dd6b0b5/detection)


win32-dwarf: 
https://sf.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/mingw-builds/7.2.0/threads-win32/dwarf/i686-7.2.0-release-win32-dwarf-rt_v5-rev1.7z
(VirusTotal report: 
https://www.virustotal.com/#/file/f8ff30b40fc362744d54ada699de53b232ce595422a5d0e97e0a01ba83ea2580/detection)



64-bit:
posix-sjlj: 
https://sf.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/mingw-builds/7.2.0/threads-posix/sjlj/x86_64-7.2.0-release-posix-sjlj-rt_v5-rev1.7z
(VirusTotal report: 
https://www.virustotal.com/#/file/01c670041d6cec863de63b214a3045e8a9f0a75dd075adf30edba4258a59/detection)


posix-seh: 
https://sf.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/mingw-builds/7.2.0/threads-posix/seh/x86_64-7.2.0-release-posix-seh-rt_v5-rev1.7z
(VirusTotal report: 
https://www.virustotal.com/#/file/ef88d8691566b993778ed3ad651a3c75bd67896d1d8e220729fe24ec405ec21c/detection)


win32-sjlj: 
https://sf.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/mingw-builds/7.2.0/threads-win32/sjlj/x86_64-7.2.0-release-win32-sjlj-rt_v5-rev1.7z
(VirusTotal report: 
https://www.virustotal.com/#/file/77f1b3116d6c34f1bca24b737b8d7856d6e994ead7df8894f09f7be7acf2071c/detection)


win32-seh: 
https://sf.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/mingw-builds/7.2.0/threads-win32/seh/x86_64-7.2.0-release-win32-seh-rt_v5-rev1.7z
(VirusTotal report: 
https://www.virustotal.com/#/file/504f66ce6ba70ec70f9232e3872c6e38e3224fd6b7c2df9c6f479a9aa834cf68/detection)




The online installer is also available:
https://sf.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/mingw-builds/installer/mingw-w64-install.exe


--
Regards, niXman
___
Work for Bitcoins
___
Dual-target(32 & 64-bit) MinGW-W64 compilers for 32 and 64-bit Windows:
https://sf.net/p/mingw-w64/

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

2017-11-14 Thread niXman 


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-rev0.7z
(VirusTotal report: 
https://www.virustotal.com/#/file/92acb8f224c85514a19de306eae88ccdad352f0dc473b7fce1afc2651e970a6f/detection)


posix-dwarf: 
https://sf.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/mingw-builds/4.9.4/threads-posix/dwarf/i686-4.9.4-release-posix-dwarf-rt_v5-rev0.7z
(VirusTotal report: 
https://www.virustotal.com/#/file/147963f992656884bf655ebc1d83426f5ff9c0a00980742b0d35d8f2b591b0ac/detection)


win32-sjlj: 
https://sf.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/mingw-builds/4.9.4/threads-win32/sjlj/i686-4.9.4-release-win32-sjlj-rt_v5-rev0.7z
(VirusTotal report: 
https://www.virustotal.com/#/file/8c17f11d077fbbf671c80de4be4818981bd25b01f65d20b114a1f24841d1d3b7/detection)


win32-dwarf: 
https://sf.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/mingw-builds/4.9.4/threads-win32/dwarf/i686-4.9.4-release-win32-dwarf-rt_v5-rev0.7z
(VirusTotal report: 
https://www.virustotal.com/#/file/b419884aedaf96afef5ba37ca315c3676e780596e6cba8d5ea2f1c1972a6a977/detection)



64-bit:
posix-sjlj: 
https://sf.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/mingw-builds/4.9.4/threads-posix/sjlj/x86_64-4.9.4-release-posix-sjlj-rt_v5-rev0.7z
(VirusTotal report: 
https://www.virustotal.com/#/file/0bf353dd6a6fe934eab568e620789792216fa8ebb071d5b3a68a4fd6ff082b97/detection)


posix-seh: 
https://sf.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/mingw-builds/4.9.4/threads-posix/seh/x86_64-4.9.4-release-posix-seh-rt_v5-rev0.7z
(VirusTotal report: 
https://www.virustotal.com/#/file/84d1a45a00653f8ae4f6216778603230b020e56073be27c05e9b0b4a1497f8a5/detection)


win32-sjlj: 
https://sf.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/mingw-builds/4.9.4/threads-win32/sjlj/x86_64-4.9.4-release-win32-sjlj-rt_v5-rev0.7z
(VirusTotal report: 
https://www.virustotal.com/#/file/ca1b4f0ae7294f3990649d942787c64a613f3d84944a072be9177dc45d9190bf/detection)


win32-seh: 
https://sf.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/mingw-builds/4.9.4/threads-win32/seh/x86_64-4.9.4-release-win32-seh-rt_v5-rev0.7z
(VirusTotal report: 
https://www.virustotal.com/#/file/d553ff40175abd7d2aa257740459b67c308ff59389e7967195e0c6a1b794fa92/detection)




The online installer is also available:
https://sf.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/mingw-builds/installer/mingw-w64-install.exe


--
Regards, niXman
___
Work for Bitcoins
___
Dual-target(32 & 64-bit) MinGW-W64 compilers for 32 and 64-bit Windows:
https://sf.net/p/mingw-w64/

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

2017-11-14 Thread David Lee 
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 observed the crash... can't imagine 
>> why it didn't crash a few days ago.
>>
>> The patch for mingw_vfscanf.c on SF is a bit complex so let me take a deep 
>> look at it.
>>
>>
>
> AFAICT the C99 standard doesn't treat the format strings of *scanf and w*canf 
> and differently.
> That is, %s always designates a narrow string and %ls always designates a 
> wide string. So are %c and %lc.
>
> Basing on that, I think the fix in 72d60c1a06490ec5937e6c620956b167bf0bf329 
> can be applied cleanly to its wide variant.
> The patch attached is confirmed to fix the crash on x86_64 and i686. Please 
> review.
>

Tried on my cross compiler and the crash went away. Thanks.

I need to test more (e.g. field width + assignment suppression for %s) though.

David Lee.

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

2017-11-14 Thread Liu Hao 
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 in the original post no longer happens on i686 and 
x86_64.

-- 
Best regards,
LH_Mouse
From c470391c15e8006c43bc8d3924d1ad44de94ed87 Mon Sep 17 00:00:00 2001
From: Liu Hao 
Date: Tue, 14 Nov 2017 10:16:24 +0800
Subject: [PATCH] stdio/mingw_wvfscanf.c: Fix segmentation fault when a char or
 string format (without malloc option) is used, like
 72d60c1a06490ec5937e6c620956b167bf0bf329.

Signed-off-by: Liu Hao 
---
 mingw-w64-crt/stdio/mingw_wvfscanf.c | 24 +++-
 1 file changed, 15 insertions(+), 9 deletions(-)

diff --git a/mingw-w64-crt/stdio/mingw_wvfscanf.c 
b/mingw-w64-crt/stdio/mingw_wvfscanf.c
index 045aba79..043c19b4 100644
--- a/mingw-w64-crt/stdio/mingw_wvfscanf.c
+++ b/mingw-w64-crt/stdio/mingw_wvfscanf.c
@@ -104,13 +104,19 @@ get_va_nth (va_list argp, unsigned int n)
 }
 
 static void
-optimize_alloc (int do_realloc, char **p, size_t sz, size_t need_sz, size_t 
typ_sz)
+optimize_alloc (char **p, char *end, size_t alloc_sz)
 {
+  size_t need_sz;
   char *h;
 
-  if (!do_realloc || sz == need_sz || !p || *p == NULL)
+  if (!p || !*p)
 return;
-  if ((h = (char *) realloc (*p, need_sz * typ_sz)) != NULL)
+
+  need_sz = end - *p;
+  if (need_sz == alloc_sz)
+return;
+
+  if ((h = (char *) realloc (*p, need_sz)) != NULL)
 *p = h;
 }
 
@@ -629,7 +635,7 @@ __mingw_swformat (_IFP *s, const wchar_t *format, va_list 
argp)
 
  if ((flags & IS_SUPPRESSED) == 0)
{
- optimize_alloc ((flags & IS_ALLOC_USED) != 0, pstr, str_sz, (str 
- *pstr), sizeof (char));
+ optimize_alloc (pstr, str, str_sz);
  pstr = NULL;
  ++rval;
}
@@ -708,7 +714,7 @@ __mingw_swformat (_IFP *s, const wchar_t *format, va_list 
argp)
 
  if ((flags & IS_SUPPRESSED) == 0)
{
- optimize_alloc ((flags & IS_ALLOC_USED) != 0, pstr, str_sz, (wstr 
- (wchar_t *) *pstr), sizeof (wchar_t));
+ optimize_alloc (pstr, (char *) wstr, str_sz * sizeof (wchar_t));
  pstr = NULL;
  ++rval;
}
@@ -824,7 +830,7 @@ __mingw_swformat (_IFP *s, const wchar_t *format, va_list 
argp)
  }
  *str++ = 0;
 
- optimize_alloc ((flags & IS_ALLOC_USED) != 0, pstr, str_sz, (str 
- *pstr), sizeof (char));
+ optimize_alloc (pstr, str, str_sz);
  pstr = NULL;
  ++rval;
}
@@ -903,7 +909,7 @@ __mingw_swformat (_IFP *s, const wchar_t *format, va_list 
argp)
{
  *wstr++ = 0;
 
- optimize_alloc ((flags & IS_ALLOC_USED) != 0, pstr, str_sz, (wstr 
- (wchar_t *) *pstr), sizeof (wchar_t));
+ optimize_alloc (pstr, (char *) wstr, str_sz * sizeof (wchar_t));
  pstr = NULL;
  ++rval;
}
@@ -1449,7 +1455,7 @@ __mingw_swformat (_IFP *s, const wchar_t *format, va_list 
argp)
{
  *wstr++ = 0;
 
- optimize_alloc ((flags & IS_ALLOC_USED) != 0, pstr, str_sz, 
(wstr - (wchar_t *) *pstr), sizeof (wchar_t));
+ optimize_alloc (pstr, (char *) wstr, str_sz * sizeof 
(wchar_t));
  pstr = NULL;
  ++rval;
}
@@ -1581,7 +1587,7 @@ __mingw_swformat (_IFP *s, const wchar_t *format, va_list 
argp)
  }
  *str++ = 0;
 
- optimize_alloc ((flags & IS_ALLOC_USED) != 0, pstr, str_sz, 
(str - *pstr), sizeof (char));
+ optimize_alloc (pstr, str, str_sz);
  pstr = NULL;
  ++rval;
}
-- 
2.14.2

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

2017-11-14 Thread Martin Storsjö 
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ö 
---
 mingw-w64-crt/lib-common/ucrtbase.def.in | 1 +
 1 file changed, 1 insertion(+)

diff --git a/mingw-w64-crt/lib-common/ucrtbase.def.in 
b/mingw-w64-crt/lib-common/ucrtbase.def.in
index 71f2af1..c809747 100644
--- a/mingw-w64-crt/lib-common/ucrtbase.def.in
+++ b/mingw-w64-crt/lib-common/ucrtbase.def.in
@@ -364,6 +364,7 @@ _fstat64i32
 _ftell_nolock
 _ftelli64
 _ftelli64_nolock
+_ftime == _ftime32
 _ftime32
 _ftime32_s
 _ftime64
-- 
2.7.4


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
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] crt: Map _find{first, next} to _find{first, next}32 on ucrtbase 32 bit x86

2017-11-14 Thread Martin Storsjö 

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 Storsjö 
---
mingw-w64-crt/lib-common/ucrtbase.def.in | 2 ++
1 file changed, 2 insertions(+)

diff --git a/mingw-w64-crt/lib-common/ucrtbase.def.in 

b/mingw-w64-crt/lib-common/ucrtbase.def.in

index 674332f..ba7dc8f 100644
--- a/mingw-w64-crt/lib-common/ucrtbase.def.in
+++ b/mingw-w64-crt/lib-common/ucrtbase.def.in
@@ -327,10 +327,12 @@ _filelength
_filelengthi64
_fileno
_findclose
+F32(_findfirst == _findfirst32)
_findfirst32
_findfirst32i64
_findfirst64
_findfirst64i32
+F32(_findnext == _findnext32)
_findnext32
_findnext32i64
_findnext64
--
2.7.4


MSVC also seems to have a similar linker alias in their libs - if I link a 
test file like this:


void _findfirst(void);
int main(int argc, char* argv[]) {
_findfirst();
return 0;
}

It ends up as a file that imports _findfirst32 from ucrtbase.dll.

This was OK'd by Jacek on irc (together with patches 1-2) if MSVC does the 
same.


Also - MSVC has got the same alias regardless of architecture - not only 
on i386, so will change this similarly before pushing.


Pushed these 3.

// Martin
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
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 _ftime32 instead of _ftime on ucrtbase

2017-11-14 Thread Martin Storsjö 

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/sys/timeb.h
+++ b/mingw-w64-headers/crt/sys/timeb.h
@@ -82,6 +82,9 @@ extern "C" {
  _CRTIMP void __cdecl _ftime(struct __timeb64 *);
#else
#define _timeb __timeb32
+#if __MSVCRT_VERSION__ >= 0x1400
+#define _ftime _ftime32
+#endif
  _CRTIMP void __cdecl _ftime(struct __timeb32 *);
#endif

--
2.7.4


Actually, it turns out that MSVC has got a linker alias for _ftime to 
_ftime32, so we can probably do the same here as well, instead of adding 
(yet) another header ifdef.


// Martin
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
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] crt: Map _find{first, next} to _find{first, next}32 on ucrtbase 32 bit x86

2017-11-14 Thread Martin Storsjö 

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.in | 2 ++
1 file changed, 2 insertions(+)

diff --git a/mingw-w64-crt/lib-common/ucrtbase.def.in 

b/mingw-w64-crt/lib-common/ucrtbase.def.in

index 674332f..ba7dc8f 100644
--- a/mingw-w64-crt/lib-common/ucrtbase.def.in
+++ b/mingw-w64-crt/lib-common/ucrtbase.def.in
@@ -327,10 +327,12 @@ _filelength
_filelengthi64
_fileno
_findclose
+F32(_findfirst == _findfirst32)
_findfirst32
_findfirst32i64
_findfirst64
_findfirst64i32
+F32(_findnext == _findnext32)
_findnext32
_findnext32i64
_findnext64
--
2.7.4


MSVC also seems to have a similar linker alias in their libs - if I link a 
test file like this:


void _findfirst(void);
int main(int argc, char* argv[]) {
_findfirst();
return 0;
}

It ends up as a file that imports _findfirst32 from ucrtbase.dll.

This was OK'd by Jacek on irc (together with patches 1-2) if MSVC does the 
same.


Also - MSVC has got the same alias regardless of architecture - not only 
on i386, so will change this similarly before pushing.


// Martin
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
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] crt: Map _find{first, next} to _find{first, next}32 on ucrtbase 32 bit x86

2017-11-14 Thread Martin Storsjö 

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(+)

diff --git a/mingw-w64-crt/lib-common/ucrtbase.def.in 
b/mingw-w64-crt/lib-common/ucrtbase.def.in
index 674332f..ba7dc8f 100644
--- a/mingw-w64-crt/lib-common/ucrtbase.def.in
+++ b/mingw-w64-crt/lib-common/ucrtbase.def.in
@@ -327,10 +327,12 @@ _filelength
_filelengthi64
_fileno
_findclose
+F32(_findfirst == _findfirst32)
_findfirst32
_findfirst32i64
_findfirst64
_findfirst64i32
+F32(_findnext == _findnext32)
_findnext32
_findnext32i64
_findnext64
--
2.7.4


MSVC also seems to have a similar linker alias in their libs - if I link a 
test file like this:


void _findfirst(void);
int main(int argc, char* argv[]) {
_findfirst();
return 0;
}

It ends up as a file that imports _findfirst32 from ucrtbase.dll.

This was OK'd by Jacek on irc (together with patches 1-2) if MSVC does the 
same.


// Martin
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

2017-11-14 Thread Jacek Caban 
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 sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

2017-11-14 Thread Shinchiro Shinchiro 
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
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public