A GCC maintainer has spoken up and said they will accept a patch to rename __in and __out to other things:
https://gcc.gnu.org/ml/gcc-help/2017-05/msg00152.html As soon as I have a bit of free time, I will submit such a patch to them, though LH_Mouse might beat me to it. So in the long term, we can have __in and __out, and we can have compatibility with libstdc++v3. I'd rather not change mingw-w64. In the MSYS2 project, we've already dealt with this issue by generating a patch for libstdc++v3 using this command I put together: sed -ri 's/\b(__in|__out)\b/_&/g' $(egrep -rl '\b(__in|__out)\b' libstdc++-v3/{include,config}) If you are compiling your own mingw-w64 toolchain, you should be capable of just running that line of code before building GCC to fix the name collision. If you are a user who is using a broken mingw-w64 toolchain, you should tell the people who built it about the line above, but in the meantime, you can edit driverspecs.h with a text editor and uncomment the lines that define __in and __out. So I think the status quo is totally fine. But if we do change mingw-w64, I can revert your change in my builds, and that works too, and it's just as easy as getting other toolchain builders to run the sed command. If we do change mingw-w64, what would be the timeline for reverting that change? Would we wait until the offending versions of libstdc++ have been replaced by fixed stable for versions for, say, 5 years? --David Grayson On Wed, May 17, 2017 at 6:18 AM, Mateusz <mateu...@poczta.onet.pl> wrote: > W dniu 2017-05-17 o 13:10, Kai Tietz pisze: >> Hello, >> >> I dislike such a change. As if somebody wants to driverspec.h, op >> will need these symbols defined. Otherwise build will badly fail. >> So this brings us back to the reasoning of this ... adding to >> specstrings.h the include of driverspecs.h. IMHO this shouldn't be >> done always. The best solution would be something like to include >> driverspecs.h in specstring.h only, if user intends to use ddk. >> Otherwise we shouldn't include this header at all. >> >> Any thoughts? >> >> Regards, >> Kai > > We could roll back commit [b7f44b]. > > Now there are new commits and this should be fixed. > > Mateusz > > > >> >> >> 2017-05-17 12:34 GMT+02:00 Mateusz <mateu...@poczta.onet.pl>: >>> We really should do something with '__in' and '__out' from driverspecs.h. >>> >>> Please review. >>> >>> >>> ------------------------------------------------------------------------------ >>> 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
