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 <davidegray...@gmail.com> 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 <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
