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 n
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++ and the headers provided
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 __i
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 M
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 m
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.) And
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
>> some
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
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 \
include/std/utili
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 ca
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 bad experiences
... especially in context of
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
libs
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 para
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 Dav
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 nam
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] Include driverspecs.h in
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 #include is after the
__cplusplus stuff.
17 matches
Mail list logo
