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 <ktiet...@googlemail.com> 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 <davidegray...@gmail.com>:
> > 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 <davidegray...@gmail.com>
> > 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 <lh_mo...@126.com> 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 <davidegray...@gmail.com>
> >>> To: Liu Hao <lh_mo...@126.com>
> >>>
> >>>
> >>>
> >>> 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 <mailto:
> >>> lh_mo...@126.com>> wrote:
> >>>
> >>> On 2017/5/10 10:34, David Grayson wrote:
> >>>
> >>> This patch adds "#include <driverspecs.h>" 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
> _______________________________________________
> 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
