On Tue, Aug 30, 2016 at 7:00 PM, Richard Purdie <[email protected]> wrote: > On Tue, 2016-08-30 at 16:37 +0100, Jack Mitchell wrote: >> Some of the headers shipped with gcc 6.1 and above now use >> #include_next >> to try to and do clever things with munging system header files. Our >> injection of isystem into the build at 'meta/conf/bitbake.conf' seems >> to >> be causing some programs to fail to compile. A full explanation can >> be >> found at [1], a bug report from GCC specifying that it should only be >> used in extreme cases at [2]. >> >> Since we seem to be adding -isystem unconditionally to BUILD_CFLAGS >> from >> bitbake, and that the default behavior has now changed should this be >> revisited? I'll admit that I am no where near experienced enough with >> GCC and friends internals to make a call on this one, I'm just >> looking >> for some input. > If I read the bug correct, the error occurs only for c++ when including STL headers (and for us on native recipes). As this combination is not that common (meta-qtx?) we have not seen fallout so far. > Its been a long time since we've looked at the native build flags and > the world is a different place from when they were first implemented > around a decade ago. I did cull some bits occasionally but more cleanup > remains and it could be we can change it. A build of all the native > recipes trying to replace it with a -I flag would likely be the first > step... > a bit off topic: I did prepare similar for cmake-native. I saw much fallout and helped myself by patching cmake-native. Will send out a patch as RFC.
Andreas -- _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
