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 <lh_mo...@126.com> 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
