Re: [Mingw-w64-public] Fwd: Re: [PATCH] Include driverspecs.h in specstrings.h.

On 2017/5/16 18:09, Jonathan Wakely wrote: > Hmm, if it's not defined when compiling with GCC then where does the > conflict come from? > These macros weren't there until recently because of the feature request by David Grayson. They don't exist in any release versions of MinGW-w64 so there is

Re: [Mingw-w64-public] Fwd: Re: [PATCH] Include driverspecs.h in specstrings.h.

On 16 May 2017 at 11:09, Jonathan Wakely wrote: > On 16 May 2017 at 11:01, Liu Hao wrote: >> On 2017/5/16 17:35, Jonathan Wakely wrote: >>> >>> On 11 May 2017 at 17:55, David Grayson wrote: Hello, gcc-help. There is an incompatibility between libstdc++

Re: [Mingw-w64-public] Fwd: Re: [PATCH] Include driverspecs.h in specstrings.h.

On 16 May 2017 at 11:01, Liu Hao wrote: > On 2017/5/16 17:35, Jonathan Wakely wrote: >> >> On 11 May 2017 at 17:55, David Grayson wrote: >>> >>> Hello, gcc-help. >>> >>> There is an incompatibility between libstdc++ and the headers provided >>> by Microsoft and mingw-w64, because libstdc++ uses

Re: [Mingw-w64-public] Fwd: Re: [PATCH] Include driverspecs.h in specstrings.h.

On 2017/5/16 17:35, Jonathan Wakely wrote: > On 11 May 2017 at 17:55, David Grayson wrote: >> Hello, gcc-help. >> >> There is an incompatibility between libstdc++ and the headers provided >> by Microsoft and mingw-w64, because libstdc++ uses __in as a parameter >> name in several places while the

Re: [Mingw-w64-public] Fwd: Re: [PATCH] Include driverspecs.h in specstrings.h.

On 11 May 2017 at 17:55, David Grayson wrote: > Hello, gcc-help. > > There is an incompatibility between libstdc++ and the headers provided > by Microsoft and mingw-w64, because libstdc++ uses __in as a parameter > name in several places while the Microsoft headers define __in as a > preprocessor

Re: [Mingw-w64-public] Fwd: Re: [PATCH] Include driverspecs.h in specstrings.h.

If I were a mingw-w64 committer, I probably wouldn't make that change, but I am OK with it. An argument in favor of that change is that it isn't too hard to just use sed or carefully-placed #defines to fix any Microsoft-style code that uses __in and __out. (It's not ideal, but not terrible.)

Re: [Mingw-w64-public] Fwd: Re: [PATCH] Include driverspecs.h in specstrings.h.

W dniu 2017-05-15 o 08:51, Liu Hao pisze: > On 2017/5/11 23:11, Kai Tietz wrote: >> I would prefer this too, but I don't believe that we can convince >> libstdc++ maintainers to modify their code for this. Sadly the MS' >> platform sdk defines a lot of stuff, which collides some times with >>

Re: [Mingw-w64-public] Fwd: Re: [PATCH] Include driverspecs.h in specstrings.h.

On 2017/5/11 23:11, Kai Tietz wrote: > I would prefer this too, but I don't believe that we can convince > libstdc++ maintainers to modify their code for this. Sadly the MS' > platform sdk defines a lot of stuff, which collides some times with > some projects. We made about this already a lot of

Re: [Mingw-w64-public] Fwd: Re: [PATCH] Include driverspecs.h in specstrings.h.

For anyone who is getting errors from the libstdc++ headers due to the name conflicts for __in and __out, here are the commands you should run when building GCC 6.3.0 to fix it: cd libstdc++-v3 sed -i 's/\b__in\b/___in/g' \ include/ext/random.tcc \ include/ext/vstring.tcc \

Re: [Mingw-w64-public] Fwd: Re: [PATCH] Include driverspecs.h in specstrings.h.

Hello, gcc-help. There is an incompatibility between libstdc++ and the headers provided by Microsoft and mingw-w64, because libstdc++ uses __in as a parameter name in several places while the Microsoft headers define __in as a preprocessor macro as part of their Source Annotation Language. You

Re: [Mingw-w64-public] Fwd: Re: [PATCH] Include driverspecs.h in specstrings.h.

Oh, I thought we should just get libstdc++ to patch their project. I would look for __in and any other badly-named parameters, and perhaps add a third underscore to their names or something like that. In the long term, that would be nicer, because then users can have Microsoft-style code and

Re: [Mingw-w64-public] Fwd: Re: [PATCH] Include driverspecs.h in specstrings.h.

On 2017/5/11 21:51, David Grayson wrote: > Unfortunately, my patch seems to break several classes in libstdc++, > preventing Qt from building. The problem is that driverspecs.h defines > __in to be empty so we can compile Microsoft-type code that uses __in as a > source annotation on function

Re: [Mingw-w64-public] Fwd: Re: [PATCH] Include driverspecs.h in specstrings.h.

Yes, that is a bit annoying ... sadly we can't do much about it. So I would suggest to add a guard to the include, so that it is user-defined, if this header should be included, or not. This might be a work-a-round for this, which should work for most. Regards, Kai 2017-05-11 15:51 GMT+02:00

Re: [Mingw-w64-public] Fwd: Re: [PATCH] Include driverspecs.h in specstrings.h.

Unfortunately, my patch seems to break several classes in libstdc++, preventing Qt from building. The problem is that driverspecs.h defines __in to be empty so we can compile Microsoft-type code that uses __in as a source annotation on function parameters while GCC's libstdc++ uses __in as the

Re: [Mingw-w64-public] Fwd: Re: [PATCH] Include driverspecs.h in specstrings.h.

Yeah, sorry, I only sent those patches to LH by mistake. Yes, I purposely used the same include guard name as Microsoft. --David On Wed, May 10, 2017 at 8:55 AM, Liu Hao wrote: > > > > Forwarded Message > Subject:Re: [Mingw-w64-public] [PATCH]

[Mingw-w64-public] Fwd: Re: [PATCH] Include driverspecs.h in specstrings.h.

Forwarded Message Subject: Re: [Mingw-w64-public] [PATCH] Include driverspecs.h in specstrings.h. Date: Wed, 10 May 2017 08:24:25 -0700 From: David Grayson To: Liu Hao OK, thanks. I've attached a new patch where the