Here's the sed command again, without bad line wrapping: https://gist.github.com/DavidEGrayson/ee9796a900eedda3d6b7c8f2324793a4
--David On Wed, May 17, 2017 at 7:08 AM, David Grayson <[email protected]> wrote: > 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 <[email protected]> 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 <[email protected]>: >>>> 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 >>>> [email protected] >>>> 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 >>> [email protected] >>> 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 >> [email protected] >> 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 [email protected] https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
