[Mingw-w64-public] Building mingw-w64 and include paths

[David Wohlferd]

One of my upcoming patches is going to be a bit controversial (or maybe 
I'm just missing something).  In either case, I'm going to go ahead and 
start the discussion early.

First a bit of vocabulary.  I'm not including this because I think 
people here don't know these terms.  It's because *I* am probably using 
them wrong.  But by defining how I am using them, hopefully you will at 
least understand what I am trying to convey.

  * SourceDir - The directory that contains the git repository of all
the mingw-w64 source files
  * BuildDir - The directory into which you will be building the output
of the files in the SourceDir.
  * OutputDir - The directory into which the useful output files
(libraries, headers, etc) will be installed when running "make
install".  Its location can be specified by using --prefix on the
configure command.
  * BinutilsDir - A loose term that encompasses the system build
utilities (gcc, clang, etc) and their support files (includes, libs,
etc).

With that in mind, here's my question: When I am building mingw-w64, 
which of these directories should the compiler be searching for include 
files, and in which order?

In my view, the correct answer (in order) is SourceDir, BuildDir, and 
BinutilsDir.  OutputDir should not be searched at all.

However, that does not appear to be what is happening.  The correct 
SourceDirs and BuildDirs frequently aren't searched at all, and 
OutputDir is.  As a result, the Mingw-w64 headers you are modifying 
while working on the project aren't used during the build (IOW you end 
up using old copies) unless you explicitly copy them around before 
running make.  While this is a hassle for people maintaining mingw-w64, 
it's got to be worse for users who "grab the latest" and don't 
understand what's required to build it.

This just seems wrong.  I believe that when building mingw-w64, the 
default should be to use the mingw-64 headers first (since that's where 
the newest files will be), then BuildDir (think: generated _mingw.h), 
then BinutilsDir (for things like ia32intrin.h, etc).  OutputDir should 
not be used at all, since it is (at best) a copy of a previous (ie 
out-of-date) build.

I have a patch for makefile.am that makes things "better" (ie adding the 
appropriate -I where needed), but I assume there's more to this issue 
than I currently understand.  Since it will probably take several emails 
for even the best teachers to fix my misunderstanding here, I'm starting 
the discussion before sending the patch.

Be gentle...

dw

--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Clean build of mingw-w64 (ie no more warning)

[Martin Storsjö]

On Tue, 16 Aug 2016, David Wohlferd wrote:


On 8/16/2016 7:30 AM, Martin Storsjö wrote:

Btw,

All of your mails end up sorted in the spam box by gmail (at least for
me), citing this reason: "It has a from address in yahoo.com but has
failed yahoo.com's required tests for authentication."

As long as I remember to check the spam box, it's fine though :-)


  It's always something.  Does this address work any better?


Just for the record - yes, this one made it through without ending up 
flagged as spam.


// Martin--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Clean build of mingw-w64 (ie no more warning)

[Jacek Caban]

On 8/17/16 12:30 AM, David Wohlferd wrote:

> Jacek?  Ktietz?  Where do we stand on my defines3.patch and
> dxgi2.patch?  Approved to push?

They are 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] Clean build of mingw-w64 (ie no more warning)

[David Wohlferd]

On 8/16/2016 7:30 AM, Martin Storsjö wrote:
> Btw,
>
> All of your mails end up sorted in the spam box by gmail (at least for
> me), citing this reason: "It has a from address in yahoo.com but has
> failed yahoo.com's required tests for authentication."
>
> As long as I remember to check the spam box, it's fine though :-)

  It's always something.  Does this address work any better?

Jacek?  Ktietz?  Where do we stand on my defines3.patch and 
dxgi2.patch?  Approved to push?

I'm rested and ready to start on the next set of patches, but I don't 
want to get too far ahead of myself.

dw



--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Autotools & git

[Jim Michaels]

a sh.exe would be exceptionally useful since windows does not provide one.

-
Jim Michaels http://www.JesusnJim.com (computer 
repair info, programming)



*From:* Ruben Van Boxem 
*To:* Jean-Baptiste Kempf ; 
"mingw-w64-public@lists.sourceforge.net" 

*Sent:* Monday, June 6, 2016 2:30 PM
*Subject:* Re: [Mingw-w64-public] Autotools & git

I for one am grateful for the configure script. I’m sure I’m not alone.

Ruben

Van: Jean-Baptiste Kempf
Verzonden: maandag 6 juni 2016 21:49
Aan: mingw-w64-public@lists.sourceforge.net 

Onderwerp: Re: [Mingw-w64-public] Autotools & git

On 06 Jun, Ozkan Sezer wrote :
 > Not everyone would have the required autofoo installed on their
 > systems to generate the configury. To me, it is polite to have the
 > generated files as they are intended to be in the repo.

If you don't have autotools, then why are you compiling mingw64? If you
are not compiling, take a tarball.

Sorry, that makes little sense to me.

-- 
Jean-Baptiste Kempf
http://www.jbkempf.com/ - +33 672 704 734
Sent from my Electronic Device
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net 

https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Clean build of mingw-w64 (ie no more warning)

[The Canadian Bacon]

It's because yahoo isn't doing proper dkim signatures, Google up the ante
on proper e-mail authentication and security.

On Aug 16, 2016 10:32 AM, "Martin Storsjö"  wrote:

> Btw,
>
> All of your mails end up sorted in the spam box by gmail (at least for
> me), citing this reason: "It has a from address in yahoo.com but has
> failed yahoo.com's required tests for authentication."
>
> As long as I remember to check the spam box, it's fine though :-)
>
> // Martin
>
> 
> --
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>
--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] [PATCH] winerror.h: Moved WINCODEC_ERR_* defines to winerror.h.

[Jacek Caban]

Signed-off-by: Jacek Caban 
---
 mingw-w64-headers/include/wincodec.h   | 16 -
 mingw-w64-headers/include/wincodec.idl | 17 --
 mingw-w64-headers/include/winerror.h   | 41
++
 3 files changed, 41 insertions(+), 33 deletions(-)


diff --git a/mingw-w64-headers/include/wincodec.h b/mingw-w64-headers/include/wincodec.h
index a863a6c..e1411cc 100644
--- a/mingw-w64-headers/include/wincodec.h
+++ b/mingw-w64-headers/include/wincodec.h
@@ -333,22 +333,6 @@ typedef struct WICBitmapPattern {
 WINBOOL EndOfStream;
 } WICBitmapPattern;
 typedef UINT32 WICColor;
-#define WINCODEC_ERR_WRONGSTATE 0x88982f04
-#define WINCODEC_ERR_VALUEOUTOFRANGE 0x88982f05
-#define WINCODEC_ERR_NOTINITIALIZED 0x88982f0c
-#define WINCODEC_ERR_ALREADYLOCKED 0x88982f0d
-#define WINCODEC_ERR_PROPERTYNOTFOUND 0x88982f40
-#define WINCODEC_ERR_CODECNOTHUMBNAIL 0x88982f44
-#define WINCODEC_ERR_PALETTEUNAVAILABLE 0x88982f45
-#define WINCODEC_ERR_COMPONENTNOTFOUND 0x88982f50
-#define WINCODEC_ERR_BADIMAGE 0x88982f60
-#define WINCODEC_ERR_FRAMEMISSING 0x88982f62
-#define WINCODEC_ERR_BADMETADATAHEADER 0x88982f63
-#define WINCODEC_ERR_UNSUPPORTEDPIXELFORMAT 0x88982f80
-#define WINCODEC_ERR_UNSUPPORTEDOPERATION 0x88982f81
-#define WINCODEC_ERR_INSUFFICIENTBUFFER 0x88982f8c
-#define WINCODEC_ERR_PROPERTYUNEXPECTEDTYPE 0x88982f8e
-#define WINCODEC_ERR_WIN32ERROR 0x88982f94
 #ifndef __IWICPalette_FWD_DEFINED__
 #define __IWICPalette_FWD_DEFINED__
 typedef interface IWICPalette IWICPalette;
diff --git a/mingw-w64-headers/include/wincodec.idl b/mingw-w64-headers/include/wincodec.idl
index 7216d07..639d925 100644
--- a/mingw-w64-headers/include/wincodec.idl
+++ b/mingw-w64-headers/include/wincodec.idl
@@ -220,23 +220,6 @@ typedef struct WICBitmapPattern {
 
 typedef UINT32 WICColor;
 
-cpp_quote("#define WINCODEC_ERR_WRONGSTATE 0x88982f04")
-cpp_quote("#define WINCODEC_ERR_VALUEOUTOFRANGE 0x88982f05")
-cpp_quote("#define WINCODEC_ERR_NOTINITIALIZED 0x88982f0c")
-cpp_quote("#define WINCODEC_ERR_ALREADYLOCKED 0x88982f0d")
-cpp_quote("#define WINCODEC_ERR_PROPERTYNOTFOUND 0x88982f40")
-cpp_quote("#define WINCODEC_ERR_CODECNOTHUMBNAIL 0x88982f44")
-cpp_quote("#define WINCODEC_ERR_PALETTEUNAVAILABLE 0x88982f45")
-cpp_quote("#define WINCODEC_ERR_COMPONENTNOTFOUND 0x88982f50")
-cpp_quote("#define WINCODEC_ERR_BADIMAGE 0x88982f60")
-cpp_quote("#define WINCODEC_ERR_FRAMEMISSING 0x88982f62")
-cpp_quote("#define WINCODEC_ERR_BADMETADATAHEADER 0x88982f63")
-cpp_quote("#define WINCODEC_ERR_UNSUPPORTEDPIXELFORMAT 0x88982f80")
-cpp_quote("#define WINCODEC_ERR_UNSUPPORTEDOPERATION 0x88982f81")
-cpp_quote("#define WINCODEC_ERR_INSUFFICIENTBUFFER 0x88982f8c")
-cpp_quote("#define WINCODEC_ERR_PROPERTYUNEXPECTEDTYPE 0x88982f8e")
-cpp_quote("#define WINCODEC_ERR_WIN32ERROR 0x88982f94")
-
 interface IWICPalette;
 
 [
diff --git a/mingw-w64-headers/include/winerror.h b/mingw-w64-headers/include/winerror.h
index 500d0a6..4667860 100644
--- a/mingw-w64-headers/include/winerror.h
+++ b/mingw-w64-headers/include/winerror.h
@@ -3543,6 +3543,47 @@ __CRT_INLINE HRESULT HRESULT_FROM_WIN32(__LONG32 x) { return x <= 0 ? (HRESULT)x
 
 #endif /*(_WIN32_WINNT >= 0x0600)*/
 
+#define WINCODEC_ERR_WRONGSTATE_HRESULT_TYPEDEF_(0x88982f04)
+#define WINCODEC_ERR_VALUEOUTOFRANGE   _HRESULT_TYPEDEF_(0x88982f05)
+#define WINCODEC_ERR_UNKNOWNIMAGEFORMAT_HRESULT_TYPEDEF_(0x88982f07)
+#define WINCODEC_ERR_UNSUPPORTEDVERSION_HRESULT_TYPEDEF_(0x88982f0b)
+#define WINCODEC_ERR_NOTINITIALIZED_HRESULT_TYPEDEF_(0x88982f0c)
+#define WINCODEC_ERR_ALREADYLOCKED _HRESULT_TYPEDEF_(0x88982f0d)
+#define WINCODEC_ERR_PROPERTYNOTFOUND  _HRESULT_TYPEDEF_(0x88982f40)
+#define WINCODEC_ERR_PROPERTYNOTSUPPORTED  _HRESULT_TYPEDEF_(0x88982f41)
+#define WINCODEC_ERR_PROPERTYSIZE  _HRESULT_TYPEDEF_(0x88982f42)
+#define WINCODEC_ERR_CODECPRESENT  _HRESULT_TYPEDEF_(0x88982f43)
+#define WINCODEC_ERR_CODECNOTHUMBNAIL  _HRESULT_TYPEDEF_(0x88982f44)
+#define WINCODEC_ERR_PALETTEUNAVAILABLE_HRESULT_TYPEDEF_(0x88982f45)
+#define WINCODEC_ERR_CODECTOOMANYSCANLINES _HRESULT_TYPEDEF_(0x88982f46)
+#define WINCODEC_ERR_INTERNALERROR _HRESULT_TYPEDEF_(0x88982f48)
+#define WINCODEC_ERR_SOURCERECTDOESNOTMATCHDIMENSIONS  _HRESULT_TYPEDEF_(0x88982f49)
+#define WINCODEC_ERR_COMPONENTNOTFOUND _HRESULT_TYPEDEF_(0x88982f50)
+#define WINCODEC_ERR_IMAGESIZEOUTOFRANGE   _HRESULT_TYPEDEF_(0x88982f51)
+#define WINCODEC_ERR_TOOMUCHMETADATA   _HRESULT_TYPEDEF_(0x88982f52)
+#define WINCODEC_ERR_BADIMAGE  _HRESULT_TYPEDEF_(0x88982f60)
+#define WINCODEC_ERR_BADHEADER

Re: [Mingw-w64-public] Clean build of mingw-w64 (ie no more warning)

[Jacek Caban]

On 16.08.2016 14:14, dw wrote:
>  cpp_quote("#define MAKE_DXGI_HRESULT(x)
> MAKE_HRESULT(1, _FACDXGI, x)")
> +cpp_quote("")
> +cpp_quote("/* These defines are (incorrectly) duplicated in winerror.h.  
> Avoid the")
> +cpp_quote("   redefine error.  */")
> +cpp_quote("#ifndef DXGI_ERROR_INVALID_CALL")
> +cpp_quote("")
>  cpp_quote("#define DXGI_ERROR_INVALID_CALL 
> MAKE_DXGI_HRESULT(1)")
>  cpp_quote("#define DXGI_ERROR_NOT_FOUND
> MAKE_DXGI_HRESULT(2)")
>  cpp_quote("#define DXGI_ERROR_MORE_DATA
> MAKE_DXGI_HRESULT(3)")
> @@ -45,6 +50,9 @@ cpp_quote("#define DXGI_ERROR_GRAPHICS_VIDPN_SOURCE_IN_USE  
>MAKE_DXGI_HRESULT
>  cpp_quote("#define DXGI_ERROR_DRIVER_INTERNAL_ERROR
> MAKE_DXGI_HRESULT(32)")
>  cpp_quote("#define DXGI_ERROR_NONEXCLUSIVE 
> MAKE_DXGI_HRESULT(33)")
>  cpp_quote("#define DXGI_ERROR_NOT_CURRENTLY_AVAILABLE  
> MAKE_DXGI_HRESULT(34)")
> +cpp_quote("")
> +cpp_quote("#endif /* DXGI_ERROR_INVALID_CALL */")
> +cpp_quote("")

Those should be removed from dxgi.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] Clean build of mingw-w64 (ie no more warning)

[dw]

On 8/16/2016 4:34 AM, Martin Storsjö wrote:
> On Tue, 16 Aug 2016, dw wrote:
>
>> Attempting to follow Martin's suggestions, I'm attaching the next three (I
>> *think* this is the organization he requested).  Ok to push?
> uchar.patch and ntsecapi.patch are ok with me.

Hearing no objections, I will push these 2.

>> = defines.patch 
>> Fix minor variations in definitions that trigger compiler warnings.
>>
>> gs_support.c:
>>   - The minor variation causes a 'redefines' error.
>> cephes_emath.h:
>>   - The minor variations cause 'redefines' errors.
>> dxgi.h:
>>   - Cheap way to avoid 'redefine' errors.
>> aviriff.h, basetyps.h, combaseapi.h, gpedit.h:
>>   - Redefine errors.
>> mfapi.h:
>>   - Redefine errors.
>> mfidl.h:
>>   - Redefine errors.
>> ntdef.h:
>>   - Redefine errors.
>> winnt.h:
>>   - Redefine errors.
> Please elaborate a bit more in the commit message about why, not only what
> you do. I guess "The minor variation causes a 'redefines' error." captures
> it, but for the future reader, it's quite condensed and not at all
> obvious unless said future reader goes back to read the mailing list.
>
> Add something like "When the same define is redefined, it only emits a
> warning if the contents of the define differs (in literal spelling, not
> only value). Make their literal spelling consistent across headers to
> avoid warnings about redefinitions."

I'll see what I can do.

> Also, the changes to dxgi.h is IMO a different solution to the same
> problem, so then it IMO should go into a separate patch,

Turns out I had to do that anyway.

> but all the other
> changes here seem to be the same. That is, I prefer having patches split
> based on what solution is taken to fix the issue, not based on what issue
> it is. Then you can afford to be a bit more verbose about the chosen
> solution in the commit message, since it's only one solution per commit.
>
> The rest of that patch seems fine to me, as long as Jacek's concern is
> handled.

Updated patch sent.  Waiting to hear from Jacek.

dw

--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Clean build of mingw-w64 (ie no more warning)

[Martin Storsjö]

On Tue, 16 Aug 2016, dw wrote:

> On 8/16/2016 4:16 AM, Jacek Caban wrote:
>> On 16.08.2016 12:50, dw wrote:
>>> --- a/mingw-w64-headers/include/mfidl.h
>>> +++ b/mingw-w64-headers/include/mfidl.h
>> This file is auto generated. You should not touch it, please change .idl
>> file instead.
>
> Strictly speaking, I believe the (duplicate) MF_xx_BYTE_ALIGNMENT defines 
> should be removed from mfidl.idl.  But for our purposes today, I can achieve 
> the desired result by just changing mfapi.h (attached as defines3.patch). 
> Better?
>
> And since you mentioned it, I checked the other files and dxgi.h is also a 
> generated file.  I have broken it out to a separate patch (dxgi.patch).
>
> = dxgi.patch 
> Avoid 'redefine' warnings from duplicated (but microscopically different) 
> defines.
>
> = defines3.patch 
> Fix minor variations in definitions that trigger compiler warnings.
>
> gs_support.c:
>  - The minor variation causes a 'redefines' error.
> cephes_emath.h:
>  - The minor variations cause 'redefines' errors.
> aviriff.h, basetyps.h, combaseapi.h, gpedit.h:
>  - Redefine errors.
> mfapi.h:
>  - Redefine errors.
> ntdef.h:
>  - Redefine errors.
> winnt.h:
>  - Redefine errors.

Both patches ok with me, but please wait for someone else's opinion as 
well.

// Martin

--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Clean build of mingw-w64 (ie no more warning)

[dw]

On 8/16/2016 4:16 AM, Jacek Caban wrote:

On 16.08.2016 12:50, dw wrote:

--- a/mingw-w64-headers/include/mfidl.h
+++ b/mingw-w64-headers/include/mfidl.h

This file is auto generated. You should not touch it, please change .idl
file instead.


Strictly speaking, I believe the (duplicate) MF_xx_BYTE_ALIGNMENT 
defines should be removed from mfidl.idl.  But for our purposes today, I 
can achieve the desired result by just changing mfapi.h (attached as 
defines3.patch).  Better?


And since you mentioned it, I checked the other files and dxgi.h is also 
a generated file.  I have broken it out to a separate patch (dxgi.patch).


= dxgi.patch 
Avoid 'redefine' warnings from duplicated (but microscopically 
different) defines.


= defines3.patch 
Fix minor variations in definitions that trigger compiler warnings.

gs_support.c:
  - The minor variation causes a 'redefines' error.
cephes_emath.h:
  - The minor variations cause 'redefines' errors.
aviriff.h, basetyps.h, combaseapi.h, gpedit.h:
  - Redefine errors.
mfapi.h:
  - Redefine errors.
ntdef.h:
  - Redefine errors.
winnt.h:
  - Redefine errors.

dw
diff --git a/mingw-w64-crt/crt/gs_support.c b/mingw-w64-crt/crt/gs_support.c
index dbd95d5..f47b0fe 100644
--- a/mingw-w64-crt/crt/gs_support.c
+++ b/mingw-w64-crt/crt/gs_support.c
@@ -26,7 +26,7 @@
 
 typedef LONG NTSTATUS;	/* same as in ntdef.h / winternl.h */
 
-#define UNW_FLAG_NHANDLER 0x00
+#define UNW_FLAG_NHANDLER   0x0
 
 typedef union
 {
diff --git a/mingw-w64-crt/math/cephes_emath.h b/mingw-w64-crt/math/cephes_emath.h
index b92d710..58a8e13 100644
--- a/mingw-w64-crt/math/cephes_emath.h
+++ b/mingw-w64-crt/math/cephes_emath.h
@@ -190,7 +190,7 @@
 #define EXONE (0x3fff)
 
 
-#define  mtherr(x,y)
+#define mtherr(fname, code)
 
 
 extern long double strtold (const char * __restrict__ s, char ** __restrict__ se);
@@ -293,7 +293,7 @@ static __inline__ void __eshdn6(register short unsigned int *x);
  */
 #define XPD 0,
 /* #define XPD */
-#define NANS
+#define NANS 1
 
 /* NaN's require infinity support. */
 #ifdef NANS
diff --git a/mingw-w64-headers/include/aviriff.h b/mingw-w64-headers/include/aviriff.h
index 30e7de3..9f4e664 100755
--- a/mingw-w64-headers/include/aviriff.h
+++ b/mingw-w64-headers/include/aviriff.h
@@ -53,12 +53,12 @@ typedef struct _rifflist {
 #define streamtypeVIDEO FCC('vids')
 #endif
 
-#define AVIF_HASINDEX 0x10
-#define AVIF_MUSTUSEINDEX 0x20
-#define AVIF_ISINTERLEAVED 0x100
-#define AVIF_TRUSTCKTYPE 0x800
-#define AVIF_WASCAPTUREFILE 0x1
-#define AVIF_COPYRIGHTED 0x2
+#define AVIF_HASINDEX 0x0010
+#define AVIF_MUSTUSEINDEX 0x0020
+#define AVIF_ISINTERLEAVED 0x0100
+#define AVIF_TRUSTCKTYPE 0x0800
+#define AVIF_WASCAPTUREFILE 0x0001
+#define AVIF_COPYRIGHTED 0x0002
 
 #ifndef AVIIF_LIST
 #define AVIIF_LIST 0x1
@@ -67,8 +67,8 @@ typedef struct _rifflist {
 #define AVIIF_NO_TIME 0x100
 #define AVIIF_COMPRESSOR 0xfff
 
-#define AVISF_DISABLED 0x1
-#define AVISF_VIDEO_PALCHANGES 0x1
+#define AVISF_DISABLED 0x0001
+#define AVISF_VIDEO_PALCHANGES 0x0001
 
 #define TIMECODE_RATE_30DROP 0
 
diff --git a/mingw-w64-headers/include/basetyps.h b/mingw-w64-headers/include/basetyps.h
index 7c36eca..dbfdcea 100644
--- a/mingw-w64-headers/include/basetyps.h
+++ b/mingw-w64-headers/include/basetyps.h
@@ -78,9 +78,9 @@
 #endif
 
 #define IFACEMETHOD(method) /*override*/ STDMETHOD (method)
-#define IFACEMETHOD_(type, method) /*override*/ STDMETHOD_ (type, method)
+#define IFACEMETHOD_(type, method) /*override*/ STDMETHOD_(type, method)
 #define IFACEMETHODV(method) /*override*/ STDMETHODV (method)
-#define IFACEMETHODV_(type, method) /*override*/ STDMETHODV_ (type, method)
+#define IFACEMETHODV_(type, method) /*override*/ STDMETHODV_(type, method)
 
 #include 
 
diff --git a/mingw-w64-headers/include/combaseapi.h b/mingw-w64-headers/include/combaseapi.h
index 3536e25..ca6483f 100644
--- a/mingw-w64-headers/include/combaseapi.h
+++ b/mingw-w64-headers/include/combaseapi.h
@@ -63,7 +63,7 @@
 #define DECLARE_INTERFACE_IID_(iface, baseiface, iid) interface DECLSPEC_UUID (iid) DECLSPEC_NOVTABLE iface : public baseiface
 
 #define IFACEMETHOD(method) STDMETHOD (method)
-#define IFACEMETHOD_(type, method) STDMETHOD_(type, method)
+#define IFACEMETHOD_(type, method) /*override*/ STDMETHOD_(type, method)
 #define IFACEMETHODV(method) STDMETHODV (method)
 #define IFACEMETHODV_(type, method) STDMETHODV_(type, method)
 
@@ -92,9 +92,9 @@ extern "C++" {
 #define STDMETHODV_(type, method) type (STDMETHODVCALLTYPE *method)
 
 #define IFACEMETHOD(method) STDMETHOD (method)
-#define IFACEMETHOD_(type, method) STDMETHOD_ (type, method)
+#define IFACEMETHOD_(type, method) /*override*/ STDMETHOD_(type, method)
 #define IFACEMETHODV(method) STDMETHODV (method)
-#define IFACEMETHODV_(type, method) STDMETHODV_ (type, method)
+#define IFACEMETHODV_(type, method) /*override*/ STDMETHODV_(type, method)
 
 #ifndef BEGIN_INTERFACE
 #define 

Re: [Mingw-w64-public] Clean build of mingw-w64 (ie no more warning)

[Martin Storsjö]

On Tue, 16 Aug 2016, dw wrote:

> Attempting to follow Martin's suggestions, I'm attaching the next three (I 
> *think* this is the organization he requested).  Ok to push?

uchar.patch and ntsecapi.patch are ok with me.

> = defines.patch 
> Fix minor variations in definitions that trigger compiler warnings.
>
> gs_support.c:
>  - The minor variation causes a 'redefines' error.
> cephes_emath.h:
>  - The minor variations cause 'redefines' errors.
> dxgi.h:
>  - Cheap way to avoid 'redefine' errors.
> aviriff.h, basetyps.h, combaseapi.h, gpedit.h:
>  - Redefine errors.
> mfapi.h:
>  - Redefine errors.
> mfidl.h:
>  - Redefine errors.
> ntdef.h:
>  - Redefine errors.
> winnt.h:
>  - Redefine errors.

Please elaborate a bit more in the commit message about why, not only what 
you do. I guess "The minor variation causes a 'redefines' error." captures 
it, but for the future reader, it's quite condensed and not at all 
obvious unless said future reader goes back to read the mailing list.

Add something like "When the same define is redefined, it only emits a 
warning if the contents of the define differs (in literal spelling, not 
only value). Make their literal spelling consistent across headers to 
avoid warnings about redefinitions."

Also, the changes to dxgi.h is IMO a different solution to the same 
problem, so then it IMO should go into a separate patch, but all the other 
changes here seem to be the same. That is, I prefer having patches split 
based on what solution is taken to fix the issue, not based on what issue 
it is. Then you can afford to be a bit more verbose about the chosen 
solution in the commit message, since it's only one solution per commit.

The rest of that patch seems fine to me, as long as Jacek's concern is 
handled.

// Martin

--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Clean build of mingw-w64 (ie no more warning)

[Jacek Caban]

On 16.08.2016 12:50, dw wrote:
>
> diff --git a/mingw-w64-headers/include/mfidl.h 
> b/mingw-w64-headers/include/mfidl.h
> index 76e8ae3..1658e58 100644
> --- a/mingw-w64-headers/include/mfidl.h
> +++ b/mingw-w64-headers/include/mfidl.h
> @@ -3399,12 +3399,12 @@ typedef struct _MFNetCredentialManagerGetParam {
>  #define MF_2_BYTE_ALIGNMENT 0x0001
>  #define MF_4_BYTE_ALIGNMENT 0x0003
>  #define MF_8_BYTE_ALIGNMENT 0x0007
> -#define MF_16_BYTE_ALIGNMENT0x000F
> -#define MF_32_BYTE_ALIGNMENT0x001F
> -#define MF_64_BYTE_ALIGNMENT0x003F
> -#define MF_128_BYTE_ALIGNMENT   0x007F
> -#define MF_256_BYTE_ALIGNMENT   0x00FF
> -#define MF_512_BYTE_ALIGNMENT   0x01FF
> +#define MF_16_BYTE_ALIGNMENT0x000f
> +#define MF_32_BYTE_ALIGNMENT0x001f
> +#define MF_64_BYTE_ALIGNMENT0x003f
> +#define MF_128_BYTE_ALIGNMENT   0x007f
> +#define MF_256_BYTE_ALIGNMENT   0x00ff
> +#define MF_512_BYTE_ALIGNMENT   0x01ff
>  
>  #define MEDIASINK_FIXED_STREAMS 0x0001
>  #define MEDIASINK_CANNOT_MATCH_CLOCK0x0002


This file is auto generated. You should not touch it, please change .idl
file 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] mingw64 gcc-6.1.0 hangs when compiling

[Ray Donnelly]

Hi Mario,

On Mon, Aug 15, 2016 at 11:29 AM, Mario Emmenlauer  wrote:
>
> Dear All,
>
> I don't know how/where to report this or how to debug the issue,
> please let me know what I can do. I tried upgrading protobuf to the
> new 3.0.0 release in Alexpux/MINGW-packages. However gcc hangs when
> compiling the tests, in file:
> https://github.com/google/protobuf/blob/master/src/google/protobuf/util/internal/protostream_objectsource_test.cc
>
> I've reported the issue in protobuf already here:
> https://github.com/google/protobuf/issues/1940
>
> However there was just the suggestion to try a different compiler.
> Can you please help me where to report this, and how to make a
> useful bug report?

Please use the MSYS2 creduce package to make a minimal test-case. It
works pretty well for this sort of thing, though you will need to do
some tricky shell code to make the shell script terminate the GCC
program after a certain amount of time, since it's an infinite loop
rather than a mis-compilation or internal compiler error.

Most likely it's a bug in GCC, so it may be worth looking around on
the GCC bugzilla bug tracker for any references to this problem.

Alternatively, try compiling MSYS2's mingw-w64-gcc-git package from
source (you may need to edit it to use the 6 branch and update it too)
using `makepkg-mingw` and see if the problem goes away. If so, we
could bisect to see what commit fixed the problem and port that across
to mingw-w64-gcc.

>
> All the best,
>
> Mario Emmenlauer
>
>
> --
> BioDataAnalysis GmbH, Mario Emmenlauer  Tel. Buero: +49-89-74677203
> Balanstr. 43   mailto: memmenlauer * biodataanalysis.de
> D-81669 München  http://www.biodataanalysis.de/
>
> --
> What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
> patterns at an interface-level. Reveals which users, apps, and protocols are
> consuming the most bandwidth. Provides multi-vendor support for NetFlow,
> J-Flow, sFlow and other flows. Make informed decisions using capacity
> planning reports. http://sdm.link/zohodev2dev
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Clean build of mingw-w64 (ie no more warning)

[dw]

On 8/16/2016 12:41 AM, Kai Tietz wrote:

 From my POV patch is ok.


Ok, I pushed that one.

Attempting to follow Martin's suggestions, I'm attaching the next three 
(I *think* this is the organization he requested).  Ok to push?


BTW, since the list now supports it, I have switched from sending .txt 
files back to sending .patch files.  I find it easier to review 
attachments if the correct program auto-launches.  But if this causes 
problems, let me know.


= defines.patch 
Fix minor variations in definitions that trigger compiler warnings.

gs_support.c:
  - The minor variation causes a 'redefines' error.
cephes_emath.h:
  - The minor variations cause 'redefines' errors.
dxgi.h:
  - Cheap way to avoid 'redefine' errors.
aviriff.h, basetyps.h, combaseapi.h, gpedit.h:
  - Redefine errors.
mfapi.h:
  - Redefine errors.
mfidl.h:
  - Redefine errors.
ntdef.h:
  - Redefine errors.
winnt.h:
  - Redefine errors.
= uchar.patch 
Fix redefinitions warnings in uchar.h.

  - __STDC_UTF_16__ & __STDC_UTF_32__ are defined by the gcc compiler.
== ntsecapi.patch ===
Fix redefinitions warnings in ntsecapi.h.

  - These redefine values that are unconditionally defined earlier in 
the same file.


dw
diff --git a/mingw-w64-crt/crt/gs_support.c b/mingw-w64-crt/crt/gs_support.c
index dbd95d5..f47b0fe 100644
--- a/mingw-w64-crt/crt/gs_support.c
+++ b/mingw-w64-crt/crt/gs_support.c
@@ -26,7 +26,7 @@
 
 typedef LONG NTSTATUS;	/* same as in ntdef.h / winternl.h */
 
-#define UNW_FLAG_NHANDLER 0x00
+#define UNW_FLAG_NHANDLER   0x0
 
 typedef union
 {
diff --git a/mingw-w64-crt/math/cephes_emath.h b/mingw-w64-crt/math/cephes_emath.h
index b92d710..58a8e13 100644
--- a/mingw-w64-crt/math/cephes_emath.h
+++ b/mingw-w64-crt/math/cephes_emath.h
@@ -190,7 +190,7 @@
 #define EXONE (0x3fff)
 
 
-#define  mtherr(x,y)
+#define mtherr(fname, code)
 
 
 extern long double strtold (const char * __restrict__ s, char ** __restrict__ se);
@@ -293,7 +293,7 @@ static __inline__ void __eshdn6(register short unsigned int *x);
  */
 #define XPD 0,
 /* #define XPD */
-#define NANS
+#define NANS 1
 
 /* NaN's require infinity support. */
 #ifdef NANS
diff --git a/mingw-w64-headers/direct-x/include/dxgi.h b/mingw-w64-headers/direct-x/include/dxgi.h
index d116b89..d056fa3 100644
--- a/mingw-w64-headers/direct-x/include/dxgi.h
+++ b/mingw-w64-headers/direct-x/include/dxgi.h
@@ -108,6 +108,11 @@ extern "C" {
 #define DXGI_STATUS_MODE_CHANGEDMAKE_DXGI_STATUS(7)
 #define DXGI_STATUS_MODE_CHANGE_IN_PROGRESS MAKE_DXGI_STATUS(8)
 #define MAKE_DXGI_HRESULT(x)MAKE_HRESULT(1, _FACDXGI, x)
+
+/* These defines are (incorrectly) duplicated in winerror.h.  Avoid the
+   redefine error.  */
+#ifndef DXGI_ERROR_INVALID_CALL
+
 #define DXGI_ERROR_INVALID_CALL MAKE_DXGI_HRESULT(1)
 #define DXGI_ERROR_NOT_FOUNDMAKE_DXGI_HRESULT(2)
 #define DXGI_ERROR_MORE_DATAMAKE_DXGI_HRESULT(3)
@@ -121,6 +126,9 @@ extern "C" {
 #define DXGI_ERROR_DRIVER_INTERNAL_ERRORMAKE_DXGI_HRESULT(32)
 #define DXGI_ERROR_NONEXCLUSIVE MAKE_DXGI_HRESULT(33)
 #define DXGI_ERROR_NOT_CURRENTLY_AVAILABLE  MAKE_DXGI_HRESULT(34)
+
+#endif /* DXGI_ERROR_INVALID_CALL */
+
 #if 0
 typedef HANDLE HMONITOR;
 typedef struct _LUID {
diff --git a/mingw-w64-headers/include/aviriff.h b/mingw-w64-headers/include/aviriff.h
index 30e7de3..9f4e664 100755
--- a/mingw-w64-headers/include/aviriff.h
+++ b/mingw-w64-headers/include/aviriff.h
@@ -53,12 +53,12 @@ typedef struct _rifflist {
 #define streamtypeVIDEO FCC('vids')
 #endif
 
-#define AVIF_HASINDEX 0x10
-#define AVIF_MUSTUSEINDEX 0x20
-#define AVIF_ISINTERLEAVED 0x100
-#define AVIF_TRUSTCKTYPE 0x800
-#define AVIF_WASCAPTUREFILE 0x1
-#define AVIF_COPYRIGHTED 0x2
+#define AVIF_HASINDEX 0x0010
+#define AVIF_MUSTUSEINDEX 0x0020
+#define AVIF_ISINTERLEAVED 0x0100
+#define AVIF_TRUSTCKTYPE 0x0800
+#define AVIF_WASCAPTUREFILE 0x0001
+#define AVIF_COPYRIGHTED 0x0002
 
 #ifndef AVIIF_LIST
 #define AVIIF_LIST 0x1
@@ -67,8 +67,8 @@ typedef struct _rifflist {
 #define AVIIF_NO_TIME 0x100
 #define AVIIF_COMPRESSOR 0xfff
 
-#define AVISF_DISABLED 0x1
-#define AVISF_VIDEO_PALCHANGES 0x1
+#define AVISF_DISABLED 0x0001
+#define AVISF_VIDEO_PALCHANGES 0x0001
 
 #define TIMECODE_RATE_30DROP 0
 
diff --git a/mingw-w64-headers/include/basetyps.h b/mingw-w64-headers/include/basetyps.h
index 7c36eca..dbfdcea 100644
--- a/mingw-w64-headers/include/basetyps.h
+++ b/mingw-w64-headers/include/basetyps.h
@@ -78,9 +78,9 @@
 #endif
 
 #define IFACEMETHOD(method) /*override*/ STDMETHOD (method)
-#define IFACEMETHOD_(type, method) /*override*/ STDMETHOD_ (type, method)
+#define IFACEMETHOD_(type, method) /*override*/ STDMETHOD_(type, method)
 #define IFACEMETHODV(method) /*override*/ STDMETHODV (method)
-#define IFACEMETHODV_(type, 

Re: [Mingw-w64-public] Clean build of mingw-w64 (ie no more warning)

[Kai Tietz]

Hi,

thanks for taking care about those warnings.  Interesting that the
redefinition is also triggered by whitespace changes, and leading
zeros ... but well, I guess it is related to partial parsing, and by
comparing for this diagnostic on not unified token stream.

From my POV patch is ok.  My personal preference is to get rid of
leading zeros, but well, I am fine.

Regards,
Kai


2016-08-16 8:45 GMT+02:00 Martin Storsjö :
> On Mon, 15 Aug 2016, dw wrote:
>
>> On 8/15/2016 4:54 AM, Martin Storsjö wrote:

 but 30 of these would be a huge hassle for the approvers as well.
>>>
>>> Not really, if they are well contained with an explanation matching it
>>> close by, it's trivial to review.
>>
>>
>> Historically my experiences haven't been good in this area.  But if you
>> are prepared to review them, I guess I can make them.
>>
 = Missing prototypes =
 clog10.c, clog10f.c, clog10l.c:
- The prototypes for the functions created in these files are
  protected by #ifdef _GNU_SOURCE.  Since we should always build
  the .c file, we need to add the define so we can find the
  prototype.
 gai_strerrorA.c:
- wcstombs() is in stdlib.
 abs64.c:
- llabs() is in stdlib.h.
 _vscprintf_p.c, _vscwprintf_p.c, _vswprintf_p.c:
- _vscprintf_p_l, _vscwprintf_p_l & _vswprintf_p_l prototypes are
  protected by #if.  Add the define so we can find them.
>>>
>>> Sure
>>
>>
>> Attached.  Ok to push?
>
>
> Remove the extra copyright disclaimer headers that you're adding. If you're
> keen on adding them, send a separate patch for that.
>
> No other objection from me, but please wait for at least somebody else to
> comment on it as well.
>
> // Martin
> --
>
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>

--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Clean build of mingw-w64 (ie no more warning)

[Martin Storsjö]

On Tue, 16 Aug 2016, dw wrote:


On 8/15/2016 11:45 PM, Martin Storsjö wrote:
Remove the extra copyright disclaimer headers that you're adding. If you're 
keen on adding them, send a separate patch for that.


I have removed the 'extra' text (attached).  Note that I am attaching 2 
files, but they are identical.  The goal is to see if text/x-patch files are 
being accepted by this list now.


I still think this level of 'purity' results in a great deal of unnecessary 
work on everyone's part.  But if this is what's required to get patches 
approved...


Anything less than this results in a commit history which is a huge pain 
to deal with afterwards.


Also keep in mind that it is absolutely trivial to do this with git, and 
you can post your full series (including attached commit messages, so that 
the commit message can be reviewed along with the diff) so that people can 
review all of them at once, instead of spoon-feeding one patch at a time 
which surely takes a lot of time and a huge number of roundtrips.


No other objection from me, but please wait for at least somebody else to 
comment on it as well.


Are you not authorized to approve patches?  Who should I be looking for email 
from then?  Or is there something about this particular patch that requires a 
closer look?


I'm just a very recent contributor, but I'm trying to get the suggested 
patches up to a level that I'm comfortable with, and that is common 
practice in other projects I've been involved with.


// Martin--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Clean build of mingw-w64 (ie no more warning)

[Martin Storsjö]

On Mon, 15 Aug 2016, dw wrote:


On 8/15/2016 4:54 AM, Martin Storsjö wrote:

but 30 of these would be a huge hassle for the approvers as well.

Not really, if they are well contained with an explanation matching it
close by, it's trivial to review.


Historically my experiences haven't been good in this area.  But if you are 
prepared to review them, I guess I can make them.



= Missing prototypes =
clog10.c, clog10f.c, clog10l.c:
   - The prototypes for the functions created in these files are
 protected by #ifdef _GNU_SOURCE.  Since we should always build
 the .c file, we need to add the define so we can find the
 prototype.
gai_strerrorA.c:
   - wcstombs() is in stdlib.
abs64.c:
   - llabs() is in stdlib.h.
_vscprintf_p.c, _vscwprintf_p.c, _vswprintf_p.c:
   - _vscprintf_p_l, _vscwprintf_p_l & _vswprintf_p_l prototypes are
 protected by #if.  Add the define so we can find them.

Sure


Attached.  Ok to push?


Remove the extra copyright disclaimer headers that you're adding. If 
you're keen on adding them, send a separate patch for that.


No other objection from me, but please wait for at least somebody else to 
comment on it as well.


// Martin--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public