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

2017-05-16 Thread Liu Hao 
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 no problem.

But in practice I (so is MSYS2, as well as David I believe) follow 
closely with git master, which got broken a few days ago.

-- 
Best regards,
LH_Mouse


--
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] Fwd: Re: [PATCH] Include driverspecs.h in specstrings.h.

2017-05-16 Thread Jonathan Wakely 
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
 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.
>>>
>>>
>>> Is it not possible to disable that noise somehow so that the macros
>>> aren't defined?
>>
>> The macros were introduced by ReactOS DDK. I have no idea where they came
>> from but I believe they must originate from Microsoft headers and nowhere
>> else.
>>
>> The disclaimer of  that defines `__in`, `__out` and `__inout`
>> describes the purpose of these macros:
>> 
>> /*
>>  * PROJECT: ReactOS DDK
>>  * COPYRIGHT:   This file is in the Public Domain.
>>  * FILE:driverspecs.h
>>  * ABSTRACT:This header stubs out Driver Verifier annotations to
>>  *  allow drivers using them to compile with our header set.
>>  */
>> 
>>
>> I am not familiar with Driver Verifier but after some quick googling it
>> seems something similar to valgrind for Windows drivers (i.e. libraries that
>> run in the kernel space).
>>
>> The macro `__in` is exposed to programs compiled using MSVC so it can hardly
>> be suppressed without causing incompatibility with MS code.
>> 
>> E:\Desktop>cat test.c
>> #include 
>> #include 
>>
>> int main(){
>> #if defined(__in)
>>  puts("__in is defined.");
>> #else
>>  puts("__in is not defined.");
>> #endif
>> }
>>
>> E:\Desktop>cl test.c /nologo /Fea.exe
>> test.c
>>
>> E:\Desktop>cat test.c
>> #include 
>> #include 
>>
>> int main(){
>> #if defined(__in)
>>  puts("__in is defined.");
>> #else
>>  puts("__in is not defined.");
>> #endif
>> }
>>
>> E:\Desktop>cl test.c /nologo /Fe:a.exe
>> test.c
>>
>> E:\Desktop>a.exe
>> __in is defined.
>>
>> E:\Desktop>gcc test.c
>>
>> E:\Desktop>a.exe
>> __in is not defined.
>> 
>
> Hmm, if it's not defined when compiling with GCC then where does the
> conflict come from?

Oh sorry, I re-read the earlier messages and understand now.

--
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] Fwd: Re: [PATCH] Include driverspecs.h in specstrings.h.

2017-05-16 Thread Jonathan Wakely 
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 __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.
>>
>>
>> Is it not possible to disable that noise somehow so that the macros
>> aren't defined?
>
> The macros were introduced by ReactOS DDK. I have no idea where they came
> from but I believe they must originate from Microsoft headers and nowhere
> else.
>
> The disclaimer of  that defines `__in`, `__out` and `__inout`
> describes the purpose of these macros:
> 
> /*
>  * PROJECT: ReactOS DDK
>  * COPYRIGHT:   This file is in the Public Domain.
>  * FILE:driverspecs.h
>  * ABSTRACT:This header stubs out Driver Verifier annotations to
>  *  allow drivers using them to compile with our header set.
>  */
> 
>
> I am not familiar with Driver Verifier but after some quick googling it
> seems something similar to valgrind for Windows drivers (i.e. libraries that
> run in the kernel space).
>
> The macro `__in` is exposed to programs compiled using MSVC so it can hardly
> be suppressed without causing incompatibility with MS code.
> 
> E:\Desktop>cat test.c
> #include 
> #include 
>
> int main(){
> #if defined(__in)
>  puts("__in is defined.");
> #else
>  puts("__in is not defined.");
> #endif
> }
>
> E:\Desktop>cl test.c /nologo /Fea.exe
> test.c
>
> E:\Desktop>cat test.c
> #include 
> #include 
>
> int main(){
> #if defined(__in)
>  puts("__in is defined.");
> #else
>  puts("__in is not defined.");
> #endif
> }
>
> E:\Desktop>cl test.c /nologo /Fe:a.exe
> test.c
>
> E:\Desktop>a.exe
> __in is defined.
>
> E:\Desktop>gcc test.c
>
> E:\Desktop>a.exe
> __in is not defined.
> 

Hmm, if it's not defined when compiling with GCC then where does the
conflict come from?


>>
>>> You can see several uses of __in in Microsoft-style code here:
>>>
>>> https://github.com/Microsoft/Windows-driver-samples/search?q=__in
>>>
>>> I would be willing to create, test, and submit a patch that changes
>>> libstdc++ to use ___in (with three underscores) to avoid this issue.
>>
>>
>> Three underscores is disgusting and wrong.
>>
>>> I expect that to be a pretty safe change that doesn't break anything.
>>> Maybe I would add a test to help prevent this from happening in the
>>> future.  Would the GCC maintainers consider accepting such a patch?
>>
>>
>> Yes, but not by simply adding an underscore.
>>
>> The patch should add "__in" to
>>
>> https://gcc.gnu.org/onlinedocs/libstdc++/manual/source_code_style.html#coding_style.bad_identifiers
>> and maybe to testsuite/17_intro/names.cc in ordr to avoid problems in
>> future.
>>
> Yes we can do that and we appreciate your respect for Windows users.

We want libstdc++ to be as portable as possible (as long as I don't
have to do all the work myself :-)

I had a quick look at our uses of __in and I think many of them could
be changed to __inp (for pointers) or __is (for istreams). A few might
need some extra thought.

--
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] Fwd: Re: [PATCH] Include driverspecs.h in specstrings.h.

2017-05-16 Thread Liu Hao 
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 Microsoft headers define __in as a
>> preprocessor macro as part of their Source Annotation Language.
> 
> Is it not possible to disable that noise somehow so that the macros
> aren't defined?
The macros were introduced by ReactOS DDK. I have no idea where they 
came from but I believe they must originate from Microsoft headers and 
nowhere else.

The disclaimer of  that defines `__in`, `__out` and 
`__inout` describes the purpose of these macros:

/*
  * PROJECT: ReactOS DDK
  * COPYRIGHT:   This file is in the Public Domain.
  * FILE:driverspecs.h
  * ABSTRACT:This header stubs out Driver Verifier annotations to
  *  allow drivers using them to compile with our header 
set.
  */


I am not familiar with Driver Verifier but after some quick googling it 
seems something similar to valgrind for Windows drivers (i.e. libraries 
that run in the kernel space).

The macro `__in` is exposed to programs compiled using MSVC so it can 
hardly be suppressed without causing incompatibility with MS code.

E:\Desktop>cat test.c
#include 
#include 

int main(){
#if defined(__in)
  puts("__in is defined.");
#else
  puts("__in is not defined.");
#endif
}

E:\Desktop>cl test.c /nologo /Fea.exe
test.c

E:\Desktop>cat test.c
#include 
#include 

int main(){
#if defined(__in)
  puts("__in is defined.");
#else
  puts("__in is not defined.");
#endif
}

E:\Desktop>cl test.c /nologo /Fe:a.exe
test.c

E:\Desktop>a.exe
__in is defined.

E:\Desktop>gcc test.c

E:\Desktop>a.exe
__in is not defined.


> 
>> You can see several uses of __in in Microsoft-style code here:
>>
>> https://github.com/Microsoft/Windows-driver-samples/search?q=__in
>>
>> I would be willing to create, test, and submit a patch that changes
>> libstdc++ to use ___in (with three underscores) to avoid this issue.
> 
> Three underscores is disgusting and wrong.
> 
>> I expect that to be a pretty safe change that doesn't break anything.
>> Maybe I would add a test to help prevent this from happening in the
>> future.  Would the GCC maintainers consider accepting such a patch?
> 
> Yes, but not by simply adding an underscore.
> 
> The patch should add "__in" to
> https://gcc.gnu.org/onlinedocs/libstdc++/manual/source_code_style.html#coding_style.bad_identifiers
> and maybe to testsuite/17_intro/names.cc in ordr to avoid problems in
> future.
> 
Yes we can do that and we appreciate your respect for Windows users.


-- 
Best regards,
LH_Mouse


--
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] Fwd: Re: [PATCH] Include driverspecs.h in specstrings.h.

2017-05-16 Thread Jonathan Wakely 
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 macro as part of their Source Annotation Language.

Is it not possible to disable that noise somehow so that the macros
aren't defined?

> You can see several uses of __in in Microsoft-style code here:
>
> https://github.com/Microsoft/Windows-driver-samples/search?q=__in
>
> I would be willing to create, test, and submit a patch that changes
> libstdc++ to use ___in (with three underscores) to avoid this issue.

Three underscores is disgusting and wrong.

> I expect that to be a pretty safe change that doesn't break anything.
> Maybe I would add a test to help prevent this from happening in the
> future.  Would the GCC maintainers consider accepting such a patch?

Yes, but not by simply adding an underscore.

The patch should add "__in" to
https://gcc.gnu.org/onlinedocs/libstdc++/manual/source_code_style.html#coding_style.bad_identifiers
and maybe to testsuite/17_intro/names.cc in order to avoid problems in
future.

--
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] Fwd: Re: [PATCH] Include driverspecs.h in specstrings.h.

2017-05-15 Thread David Grayson 
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 once we get libstdc++ to stop using those names,
we could undo the change.

And if we do change mingw-w64, I agree the way to do it is to comment
out the __in and __out lines in driverspecs.h, rather than reverting
the patch I posted at the beginning of this thread.

--David

On Mon, May 15, 2017 at 1:57 AM, Mateusz  wrote:
> 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 projects.  We made about this already a lot of bad experiences
>>> ... especially in context of MIDL ... defining
>>> IN/OUT/INOUT/OPTIONAL/etc is really no clever move ...
>>> Nevertheless it might be worth a try to ask libstdc++ people for those
>>> __in A good argument (and bad one too) might be that the double
>>> underscore symbols are reserved to compilers/system headers.  And
>>> well, C++ headers aren't really system headers, which is in general
>>> just a POV ;)
>> I suggest we comment out `__in` and `__out` from _driverspecs.h_. The
>> compatibility with GNU libstdc++ and LLVM libcxx is more essential than
>> that with Windows in my opinion.
>
> +1
>
>>
>> These macros are defined after including _windows.h_ from official
>> Windows SDK, as shown in this example:
>>
>> 
>> E:\Desktop>cat test.c
>> #include 
>> #include 
>>
>> int main(){
>> #if defined(__in)
>>  puts("__in is defined.");
>> #else
>>  puts("__in is not defined.");
>> #endif
>> }
>>
>> E:\Desktop>cl test.c /nologo /Fea.exe
>> test.c
>>
>> E:\Desktop>cat test.c
>> #include 
>> #include 
>>
>> int main(){
>> #if defined(__in)
>>  puts("__in is defined.");
>> #else
>>  puts("__in is not defined.");
>> #endif
>> }
>>
>> E:\Desktop>cl test.c /nologo /Fe:a.exe
>> test.c
>>
>> E:\Desktop>a.exe
>> __in is defined.
>>
>> E:\Desktop>gcc test.c
>>
>> E:\Desktop>a.exe
>> __in is not defined.
>> 
>>
>>
>
>
> --
> 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

--
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] Fwd: Re: [PATCH] Include driverspecs.h in specstrings.h.

2017-05-15 Thread Mateusz 
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 projects.  We made about this already a lot of bad experiences
>> ... especially in context of MIDL ... defining
>> IN/OUT/INOUT/OPTIONAL/etc is really no clever move ...
>> Nevertheless it might be worth a try to ask libstdc++ people for those
>> __in A good argument (and bad one too) might be that the double
>> underscore symbols are reserved to compilers/system headers.  And
>> well, C++ headers aren't really system headers, which is in general
>> just a POV ;)
> I suggest we comment out `__in` and `__out` from _driverspecs.h_. The 
> compatibility with GNU libstdc++ and LLVM libcxx is more essential than 
> that with Windows in my opinion.

+1

> 
> These macros are defined after including _windows.h_ from official 
> Windows SDK, as shown in this example:
> 
> 
> E:\Desktop>cat test.c
> #include 
> #include 
> 
> int main(){
> #if defined(__in)
>  puts("__in is defined.");
> #else
>  puts("__in is not defined.");
> #endif
> }
> 
> E:\Desktop>cl test.c /nologo /Fea.exe
> test.c
> 
> E:\Desktop>cat test.c
> #include 
> #include 
> 
> int main(){
> #if defined(__in)
>  puts("__in is defined.");
> #else
>  puts("__in is not defined.");
> #endif
> }
> 
> E:\Desktop>cl test.c /nologo /Fe:a.exe
> test.c
> 
> E:\Desktop>a.exe
> __in is defined.
> 
> E:\Desktop>gcc test.c
> 
> E:\Desktop>a.exe
> __in is not defined.
> 
> 
> 


--
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] Fwd: Re: [PATCH] Include driverspecs.h in specstrings.h.

2017-05-15 Thread Liu Hao 
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 bad experiences
> ... especially in context of MIDL ... defining
> IN/OUT/INOUT/OPTIONAL/etc is really no clever move ...
> Nevertheless it might be worth a try to ask libstdc++ people for those
> __in A good argument (and bad one too) might be that the double
> underscore symbols are reserved to compilers/system headers.  And
> well, C++ headers aren't really system headers, which is in general
> just a POV ;)
I suggest we comment out `__in` and `__out` from _driverspecs.h_. The 
compatibility with GNU libstdc++ and LLVM libcxx is more essential than 
that with Windows in my opinion.

These macros are defined after including _windows.h_ from official 
Windows SDK, as shown in this example:


E:\Desktop>cat test.c
#include 
#include 

int main(){
#if defined(__in)
 puts("__in is defined.");
#else
 puts("__in is not defined.");
#endif
}

E:\Desktop>cl test.c /nologo /Fea.exe
test.c

E:\Desktop>cat test.c
#include 
#include 

int main(){
#if defined(__in)
 puts("__in is defined.");
#else
 puts("__in is not defined.");
#endif
}

E:\Desktop>cl test.c /nologo /Fe:a.exe
test.c

E:\Desktop>a.exe
__in is defined.

E:\Desktop>gcc test.c

E:\Desktop>a.exe
__in is not defined.



-- 
Best regards,
LH_Mouse


--
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] Fwd: Re: [PATCH] Include driverspecs.h in specstrings.h.

2017-05-12 Thread David Grayson 
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/utility \
  include/std/tuple \
  include/std/istream \
  include/tr2/bool_set.tcc \
  include/tr2/bool_set \
  include/bits/basic_string.h \
  include/bits/basic_string.tcc \
  include/bits/locale_facets.h \
  include/bits/istream.tcc \
  include/tr1/utility \
  include/tr1/tuple
sed -i 's/\b__out\b/___out/g' \
  include/ext/random.tcc \
  include/ext/algorithm \
  include/ext/pb_ds/detail/debug_map_base.hpp \
  include/std/ostream \
  include/std/thread \
  include/tr2/bool_set \
  include/bits/ostream.tcc \
  include/bits/regex.tcc \
  include/bits/stl_algo.h \
  include/bits/locale_conv.h \
  include/bits/regex.h \
  include/bits/ostream_insert.h \
  include/tr1/regex \
  include/parallel/algo.h \
  include/parallel/set_operations.h \
  include/parallel/multiway_merge.h \
  include/parallel/unique_copy.h \
  include/experimental/algorithm \
  config/locale/dragonfly/c_locale.h \
  config/locale/generic/c_locale.h \
  config/locale/gnu/c_locale.h

--David

On Thu, May 11, 2017 at 9:55 AM, 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 macro as part of their Source Annotation Language.
>
> You can see several uses of __in in Microsoft-style code here:
>
> https://github.com/Microsoft/Windows-driver-samples/search?q=__in
>
> I would be willing to create, test, and submit a patch that changes
> libstdc++ to use ___in (with three underscores) to avoid this issue.
> I expect that to be a pretty safe change that doesn't break anything.
> Maybe I would add a test to help prevent this from happening in the
> future.  Would the GCC maintainers consider accepting such a patch?
>
> Please note that I'm not trying to assign blame, I'm just trying to
> get Qt to compile with the latest mingw-w64 without using hacky
> workarounds.
>
> --David
>
> On Thu, May 11, 2017 at 7:29 AM, Liu Hao  wrote:
>> 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 parameters while GCC's libstdc++ uses __in as
>>> the name of an input argument for many of its methods:
>>>
>>> $ egrep -lr '\b__in\b' /mingw32/include/
>>> /mingw32/include/c++/6.3.0/bits/basic_string.h
>>> /mingw32/include/c++/6.3.0/bits/basic_string.tcc
>>> /mingw32/include/c++/6.3.0/bits/istream.tcc
>>> /mingw32/include/c++/6.3.0/bits/locale_facets.h
>>> /mingw32/include/c++/6.3.0/ext/random.tcc
>>> /mingw32/include/c++/6.3.0/ext/vstring.tcc
>>> /mingw32/include/c++/6.3.0/istream
>>> /mingw32/include/c++/6.3.0/tr1/tuple
>>> /mingw32/include/c++/6.3.0/tr1/utility
>>> /mingw32/include/c++/6.3.0/tr2/bool_set
>>> /mingw32/include/c++/6.3.0/tr2/bool_set.tcc
>>> /mingw32/include/c++/6.3.0/tuple
>>> /mingw32/include/c++/6.3.0/utility
>>>
>>> One of the errors I get looks like this:
>>>
>>> /nix/.../include/c++/6.3.0/utility:208:57: error: no matching function for
>>> call to 'move()'
>>>   { return __pair_get<_Int>::__move_get(std::move(__in)); }
>>>
>>> I don't think this is necessarily a problem with mingw-w64, or a problem
>>> with that patch.  Adrien Nader's attitude on this mailing list in
>>> 2015-11-03 was "Really, there's a platform and software is built on top of
>>> it; it is that software that is supposed to adapt to the platform."  
>>> Microsoft
>>> Windows and mingw-w64 are platforms that define __in to have a special
>>> meaning.  The software built on that platform (libstdc++) should adapt to
>>> the platform.
>> I CC'd gcc-help. Hope it helps.
>> Anyway Windows headers are really a can of worms (think about the macros
>> `min` and `max` for example).
>>
>>> One odd thing is that our __in gets defined in driverspecs.h, while
>>> Microsoft defines their __in in sal.h.  But specstrings.h (for both
>>> mingw-w64 and Microsoft) includes both sal.h and driverspecs.h so that
>>> shouldn't affect when the bug appears.
>> Both headers seem to be out of sync for years. I hope they can be
>> updated someday.

--
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

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

2017-05-11 Thread David Grayson 
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 can see several uses of __in in Microsoft-style code here:

https://github.com/Microsoft/Windows-driver-samples/search?q=__in

I would be willing to create, test, and submit a patch that changes
libstdc++ to use ___in (with three underscores) to avoid this issue.
I expect that to be a pretty safe change that doesn't break anything.
Maybe I would add a test to help prevent this from happening in the
future.  Would the GCC maintainers consider accepting such a patch?

Please note that I'm not trying to assign blame, I'm just trying to
get Qt to compile with the latest mingw-w64 without using hacky
workarounds.

--David

On Thu, May 11, 2017 at 7:29 AM, Liu Hao  wrote:
> 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 parameters while GCC's libstdc++ uses __in as
>> the name of an input argument for many of its methods:
>>
>> $ egrep -lr '\b__in\b' /mingw32/include/
>> /mingw32/include/c++/6.3.0/bits/basic_string.h
>> /mingw32/include/c++/6.3.0/bits/basic_string.tcc
>> /mingw32/include/c++/6.3.0/bits/istream.tcc
>> /mingw32/include/c++/6.3.0/bits/locale_facets.h
>> /mingw32/include/c++/6.3.0/ext/random.tcc
>> /mingw32/include/c++/6.3.0/ext/vstring.tcc
>> /mingw32/include/c++/6.3.0/istream
>> /mingw32/include/c++/6.3.0/tr1/tuple
>> /mingw32/include/c++/6.3.0/tr1/utility
>> /mingw32/include/c++/6.3.0/tr2/bool_set
>> /mingw32/include/c++/6.3.0/tr2/bool_set.tcc
>> /mingw32/include/c++/6.3.0/tuple
>> /mingw32/include/c++/6.3.0/utility
>>
>> One of the errors I get looks like this:
>>
>> /nix/.../include/c++/6.3.0/utility:208:57: error: no matching function for
>> call to 'move()'
>>   { return __pair_get<_Int>::__move_get(std::move(__in)); }
>>
>> I don't think this is necessarily a problem with mingw-w64, or a problem
>> with that patch.  Adrien Nader's attitude on this mailing list in
>> 2015-11-03 was "Really, there's a platform and software is built on top of
>> it; it is that software that is supposed to adapt to the platform."  
>> Microsoft
>> Windows and mingw-w64 are platforms that define __in to have a special
>> meaning.  The software built on that platform (libstdc++) should adapt to
>> the platform.
> I CC'd gcc-help. Hope it helps.
> Anyway Windows headers are really a can of worms (think about the macros
> `min` and `max` for example).
>
>> One odd thing is that our __in gets defined in driverspecs.h, while
>> Microsoft defines their __in in sal.h.  But specstrings.h (for both
>> mingw-w64 and Microsoft) includes both sal.h and driverspecs.h so that
>> shouldn't affect when the bug appears.
> Both headers seem to be out of sync for years. I hope they can be
> updated someday.

--
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] Fwd: Re: [PATCH] Include driverspecs.h in specstrings.h.

2017-05-11 Thread David Grayson 
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
libstdc++ code used in the same translation unit and they don't have to
remember to use a guard on the include.

--David

On Thu, May 11, 2017 at 7:24 AM, Kai Tietz  wrote:

> 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 David Grayson :
> > 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 name of an input argument for many of its methods:
> >
> > $ egrep -lr '\b__in\b' /mingw32/include/
> > /mingw32/include/c++/6.3.0/bits/basic_string.h
> > /mingw32/include/c++/6.3.0/bits/basic_string.tcc
> > /mingw32/include/c++/6.3.0/bits/istream.tcc
> > /mingw32/include/c++/6.3.0/bits/locale_facets.h
> > /mingw32/include/c++/6.3.0/ext/random.tcc
> > /mingw32/include/c++/6.3.0/ext/vstring.tcc
> > /mingw32/include/c++/6.3.0/istream
> > /mingw32/include/c++/6.3.0/tr1/tuple
> > /mingw32/include/c++/6.3.0/tr1/utility
> > /mingw32/include/c++/6.3.0/tr2/bool_set
> > /mingw32/include/c++/6.3.0/tr2/bool_set.tcc
> > /mingw32/include/c++/6.3.0/tuple
> > /mingw32/include/c++/6.3.0/utility
> >
> > One of the errors I get looks like this:
> >
> > /nix/.../include/c++/6.3.0/utility:208:57: error: no matching function
> for
> > call to 'move()'
> >  { return __pair_get<_Int>::__move_get(std::move(__in)); }
> >
> > I don't think this is necessarily a problem with mingw-w64, or a problem
> > with that patch.  Adrien Nader's attitude on this mailing list in
> > 2015-11-03 was "Really, there's a platform and software is built on top
> of
> > it; it is that software that is supposed to adapt to the platform."
> Microsoft
> > Windows and mingw-w64 are platforms that define __in to have a special
> > meaning.  The software built on that platform (libstdc++) should adapt to
> > the platform.
> >
> > One odd thing is that our __in gets defined in driverspecs.h, while
> > Microsoft defines their __in in sal.h.  But specstrings.h (for both
> > mingw-w64 and Microsoft) includes both sal.h and driverspecs.h so that
> > shouldn't affect when the bug appears.
> >
> > --David Grayson
> >
> > On Wed, May 10, 2017 at 9:44 AM, David Grayson 
> > wrote:
> >
> >> 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
> >>> 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.
> >>>
> >>> I also included a second patch that will add an include guard for
> >>> specstrings.h, since Microsoft seems to do that too.
> >>>
> >>> driverspecs.h is also missing an include guard but it is part of the
> >>> React DDK so I didn't want to mess around with editing at the moment.
> >>>
> >>> --David
> >>>
> >>> On Tue, May 9, 2017 at 9:07 PM, Liu Hao >> lh_mo...@126.com>> wrote:
> >>>
> >>> On 2017/5/10 10:34, David Grayson wrote:
> >>>
> >>> This patch adds "#include " near the end of
> >>> specstrings.h,
> >>> because the same is done in Microsoft's version of
> >>> specstrings.h.  With
> >>> this patch, I am able to build Microsoft's devcon utility
> without
> >>> modification.  Thanks!
> >>>
> >>> You must `#include` that header AFTER the `#ifdef __cplusplus ...
> >>> #endif` block.
> >>>
> >>> Anyway, this header seems short of a header guard. I shall ask
> >>> someone for sure.
> >>>
> >>> -- Best regards,
> >>> LH_Mouse
> >>>
> >>>
> >>>
> >>> 
> >>> --
> >>> 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
>

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

2017-05-11 Thread Liu Hao 
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 parameters while GCC's libstdc++ uses __in as
> the name of an input argument for many of its methods:
> 
> $ egrep -lr '\b__in\b' /mingw32/include/
> /mingw32/include/c++/6.3.0/bits/basic_string.h
> /mingw32/include/c++/6.3.0/bits/basic_string.tcc
> /mingw32/include/c++/6.3.0/bits/istream.tcc
> /mingw32/include/c++/6.3.0/bits/locale_facets.h
> /mingw32/include/c++/6.3.0/ext/random.tcc
> /mingw32/include/c++/6.3.0/ext/vstring.tcc
> /mingw32/include/c++/6.3.0/istream
> /mingw32/include/c++/6.3.0/tr1/tuple
> /mingw32/include/c++/6.3.0/tr1/utility
> /mingw32/include/c++/6.3.0/tr2/bool_set
> /mingw32/include/c++/6.3.0/tr2/bool_set.tcc
> /mingw32/include/c++/6.3.0/tuple
> /mingw32/include/c++/6.3.0/utility
> 
> One of the errors I get looks like this:
> 
> /nix/.../include/c++/6.3.0/utility:208:57: error: no matching function for
> call to 'move()'
>   { return __pair_get<_Int>::__move_get(std::move(__in)); }
> 
> I don't think this is necessarily a problem with mingw-w64, or a problem
> with that patch.  Adrien Nader's attitude on this mailing list in
> 2015-11-03 was "Really, there's a platform and software is built on top of
> it; it is that software that is supposed to adapt to the platform."  Microsoft
> Windows and mingw-w64 are platforms that define __in to have a special
> meaning.  The software built on that platform (libstdc++) should adapt to
> the platform.
I CC'd gcc-help. Hope it helps.
Anyway Windows headers are really a can of worms (think about the macros 
`min` and `max` for example).

> One odd thing is that our __in gets defined in driverspecs.h, while
> Microsoft defines their __in in sal.h.  But specstrings.h (for both
> mingw-w64 and Microsoft) includes both sal.h and driverspecs.h so that
> shouldn't affect when the bug appears.
Both headers seem to be out of sync for years. I hope they can be 
updated someday.


-- 
Best regards,
LH_Mouse


--
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] Fwd: Re: [PATCH] Include driverspecs.h in specstrings.h.

2017-05-11 Thread Kai Tietz 
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 David Grayson :
> 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 name of an input argument for many of its methods:
>
> $ egrep -lr '\b__in\b' /mingw32/include/
> /mingw32/include/c++/6.3.0/bits/basic_string.h
> /mingw32/include/c++/6.3.0/bits/basic_string.tcc
> /mingw32/include/c++/6.3.0/bits/istream.tcc
> /mingw32/include/c++/6.3.0/bits/locale_facets.h
> /mingw32/include/c++/6.3.0/ext/random.tcc
> /mingw32/include/c++/6.3.0/ext/vstring.tcc
> /mingw32/include/c++/6.3.0/istream
> /mingw32/include/c++/6.3.0/tr1/tuple
> /mingw32/include/c++/6.3.0/tr1/utility
> /mingw32/include/c++/6.3.0/tr2/bool_set
> /mingw32/include/c++/6.3.0/tr2/bool_set.tcc
> /mingw32/include/c++/6.3.0/tuple
> /mingw32/include/c++/6.3.0/utility
>
> One of the errors I get looks like this:
>
> /nix/.../include/c++/6.3.0/utility:208:57: error: no matching function for
> call to 'move()'
>  { return __pair_get<_Int>::__move_get(std::move(__in)); }
>
> I don't think this is necessarily a problem with mingw-w64, or a problem
> with that patch.  Adrien Nader's attitude on this mailing list in
> 2015-11-03 was "Really, there's a platform and software is built on top of
> it; it is that software that is supposed to adapt to the platform."  Microsoft
> Windows and mingw-w64 are platforms that define __in to have a special
> meaning.  The software built on that platform (libstdc++) should adapt to
> the platform.
>
> One odd thing is that our __in gets defined in driverspecs.h, while
> Microsoft defines their __in in sal.h.  But specstrings.h (for both
> mingw-w64 and Microsoft) includes both sal.h and driverspecs.h so that
> shouldn't affect when the bug appears.
>
> --David Grayson
>
> On Wed, May 10, 2017 at 9:44 AM, David Grayson 
> wrote:
>
>> 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
>>> 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.
>>>
>>> I also included a second patch that will add an include guard for
>>> specstrings.h, since Microsoft seems to do that too.
>>>
>>> driverspecs.h is also missing an include guard but it is part of the
>>> React DDK so I didn't want to mess around with editing at the moment.
>>>
>>> --David
>>>
>>> On Tue, May 9, 2017 at 9:07 PM, Liu Hao > lh_mo...@126.com>> wrote:
>>>
>>> On 2017/5/10 10:34, David Grayson wrote:
>>>
>>> This patch adds "#include " near the end of
>>> specstrings.h,
>>> because the same is done in Microsoft's version of
>>> specstrings.h.  With
>>> this patch, I am able to build Microsoft's devcon utility without
>>> modification.  Thanks!
>>>
>>> You must `#include` that header AFTER the `#ifdef __cplusplus ...
>>> #endif` block.
>>>
>>> Anyway, this header seems short of a header guard. I shall ask
>>> someone for sure.
>>>
>>> -- Best regards,
>>> LH_Mouse
>>>
>>>
>>>
>>> 
>>> --
>>> 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
>>>
>>>
>>
> --
> 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

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot

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

2017-05-11 Thread David Grayson 
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 name of an input argument for many of its methods:

$ egrep -lr '\b__in\b' /mingw32/include/
/mingw32/include/c++/6.3.0/bits/basic_string.h
/mingw32/include/c++/6.3.0/bits/basic_string.tcc
/mingw32/include/c++/6.3.0/bits/istream.tcc
/mingw32/include/c++/6.3.0/bits/locale_facets.h
/mingw32/include/c++/6.3.0/ext/random.tcc
/mingw32/include/c++/6.3.0/ext/vstring.tcc
/mingw32/include/c++/6.3.0/istream
/mingw32/include/c++/6.3.0/tr1/tuple
/mingw32/include/c++/6.3.0/tr1/utility
/mingw32/include/c++/6.3.0/tr2/bool_set
/mingw32/include/c++/6.3.0/tr2/bool_set.tcc
/mingw32/include/c++/6.3.0/tuple
/mingw32/include/c++/6.3.0/utility

One of the errors I get looks like this:

/nix/.../include/c++/6.3.0/utility:208:57: error: no matching function for
call to 'move()'
 { return __pair_get<_Int>::__move_get(std::move(__in)); }

I don't think this is necessarily a problem with mingw-w64, or a problem
with that patch.  Adrien Nader's attitude on this mailing list in
2015-11-03 was "Really, there's a platform and software is built on top of
it; it is that software that is supposed to adapt to the platform."  Microsoft
Windows and mingw-w64 are platforms that define __in to have a special
meaning.  The software built on that platform (libstdc++) should adapt to
the platform.

One odd thing is that our __in gets defined in driverspecs.h, while
Microsoft defines their __in in sal.h.  But specstrings.h (for both
mingw-w64 and Microsoft) includes both sal.h and driverspecs.h so that
shouldn't affect when the bug appears.

--David Grayson

On Wed, May 10, 2017 at 9:44 AM, David Grayson 
wrote:

> 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
>> 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.
>>
>> I also included a second patch that will add an include guard for
>> specstrings.h, since Microsoft seems to do that too.
>>
>> driverspecs.h is also missing an include guard but it is part of the
>> React DDK so I didn't want to mess around with editing at the moment.
>>
>> --David
>>
>> On Tue, May 9, 2017 at 9:07 PM, Liu Hao  lh_mo...@126.com>> wrote:
>>
>> On 2017/5/10 10:34, David Grayson wrote:
>>
>> This patch adds "#include " near the end of
>> specstrings.h,
>> because the same is done in Microsoft's version of
>> specstrings.h.  With
>> this patch, I am able to build Microsoft's devcon utility without
>> modification.  Thanks!
>>
>> You must `#include` that header AFTER the `#ifdef __cplusplus ...
>> #endif` block.
>>
>> Anyway, this header seems short of a header guard. I shall ask
>> someone for sure.
>>
>> -- Best regards,
>> LH_Mouse
>>
>>
>>
>> 
>> --
>> 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
>>
>>
>
--
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] Fwd: Re: [PATCH] Include driverspecs.h in specstrings.h.

2017-05-10 Thread David Grayson 
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
> 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.
>
> I also included a second patch that will add an include guard for
> specstrings.h, since Microsoft seems to do that too.
>
> driverspecs.h is also missing an include guard but it is part of the React
> DDK so I didn't want to mess around with editing at the moment.
>
> --David
>
> On Tue, May 9, 2017 at 9:07 PM, Liu Hao > wrote:
>
> On 2017/5/10 10:34, David Grayson wrote:
>
> This patch adds "#include " near the end of
> specstrings.h,
> because the same is done in Microsoft's version of
> specstrings.h.  With
> this patch, I am able to build Microsoft's devcon utility without
> modification.  Thanks!
>
> You must `#include` that header AFTER the `#ifdef __cplusplus ...
> #endif` block.
>
> Anyway, this header seems short of a header guard. I shall ask
> someone for sure.
>
> -- Best regards,
> LH_Mouse
>
>
>
> 
> --
> 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
>
>
--
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] Fwd: Re: [PATCH] Include driverspecs.h in specstrings.h.

2017-05-10 Thread Liu Hao 




 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.


I also included a second patch that will add an include guard for 
specstrings.h, since Microsoft seems to do that too.


driverspecs.h is also missing an include guard but it is part of the 
React DDK so I didn't want to mess around with editing at the moment.


--David

On Tue, May 9, 2017 at 9:07 PM, Liu Hao > wrote:


On 2017/5/10 10:34, David Grayson wrote:

This patch adds "#include " near the end of
specstrings.h,
because the same is done in Microsoft's version of
specstrings.h.  With
this patch, I am able to build Microsoft's devcon utility without
modification.  Thanks!

You must `#include` that header AFTER the `#ifdef __cplusplus ...
#endif` block.

Anyway, this header seems short of a header guard. I shall ask
someone for sure.

-- Best regards,
LH_Mouse


From bb87ae14e5a381617d1969837efd0d9c3ddefa25 Mon Sep 17 00:00:00 2001
From: David Grayson 
Date: Tue, 9 May 2017 09:15:29 -0700
Subject: [PATCH 1/2] specstrings.h:  Include driverspecs.h near the bottom.

That's what the Microsoft header does, and their devcon utility
depends on it.
---
 mingw-w64-headers/include/specstrings.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/mingw-w64-headers/include/specstrings.h 
b/mingw-w64-headers/include/specstrings.h
index 485b4330..984dd64b 100644
--- a/mingw-w64-headers/include/specstrings.h
+++ b/mingw-w64-headers/include/specstrings.h
@@ -328,3 +328,5 @@ extern "C" {
 #ifdef __cplusplus
 }
 #endif
+
+#include 
-- 
2.12.1

From 65c70e8cad7d6c234b00a4d3240a98cae49465e7 Mon Sep 17 00:00:00 2001
From: David Grayson 
Date: Wed, 10 May 2017 07:07:04 -0700
Subject: [PATCH 2/2] specstrings.h: Add an include guard.

---
 mingw-w64-headers/include/specstrings.h | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/mingw-w64-headers/include/specstrings.h 
b/mingw-w64-headers/include/specstrings.h
index 984dd64b..bcb9fc3c 100644
--- a/mingw-w64-headers/include/specstrings.h
+++ b/mingw-w64-headers/include/specstrings.h
@@ -3,6 +3,10 @@
  * This file is part of the mingw-w64 runtime package.
  * No warranty is given; refer to the file DISCLAIMER.PD within this package.
  */
+
+#ifndef SPECSTRINGS_H
+#define SPECSTRINGS_H
+
 #define __specstrings
 
 #include 
@@ -330,3 +334,5 @@ extern "C" {
 #endif
 
 #include 
+
+#endif
-- 
2.12.1

--
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