MXE with Qt5.9.2 + GCC 7.2.0 build error

Lubomir I. Ivanov neolit123 at gmail.com
Thu Oct 12 10:13:34 PDT 2017


On 12 October 2017 at 19:48, Stefan Fuchs <sfuchs at gmx.de> wrote:
> Hi Lubomir,
>
>
> Am 12.10.2017 um 12:34 schrieb Lubomir I. Ivanov:
>>
>> this looks like something which isn't a problem on the subsurface side.
>> my bet is that the mingw 7x "dudes" are doing something wrong with
>> #include_next.
>>
>> fixing compiler headers is always a bad idea, so i'd suggest that you
>> try another compiler and report the issue to MXE.
>>
> I looked a little bit around and found this:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70129
> https://github.com/OpenLightingProject/ola/issues/1125
>
> Maybe we can and should fix it in our makefiles because gcc 6 and 7 can be
> affected?
>

what happens if you try to build this example application with the
toolchain in question - would you get the same error?
http://www.cplusplus.com/reference/algorithm/sort/

#include_next as a GCC extension is pure evil.
it's evil, because you can do all sorts of gymnastics with it in the
system headers, but then the pre-processor search order can be changed
by library X for a certain translation unit and the whole "next"
aspect is now broken. depending on "next" in the search order is a bad
design decision IMO....it might be Qt that is doing the re-ordering,
but unless you debug this the way the developer from Github did, there
is no way to know what is happening exactly.

my guess is that the above C++ example will work without issues, but
if it fails then the toolchain itself seems broken.
if it works then it's probably Qt or MXE that are doing something bad
to not account for this particular use of #include_next.

given most of us are still on the 5.x series, i would wait for others
(Qt, MXE, GCC) to take actions for this..

lubomir
--


More information about the subsurface mailing list