Re: [OE-core] gcc 6.1+ and isystem
> On Aug 30, 2016, at 8:37 AM, 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]. you can say with isystem gcc let its users play smart things with its internal header search path order. > > 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. > Yes, I am aware of this fact and there has been a change to remove -isystem from BUILDSDK_CPPFLAGS, the problem with BUILD_CPPFLAGS is different since it was added intentionally to override the system headers is in direct conflict with what -isystem use is recommended for. If we were just complementing the default system includedirs it would be different however. Should be not use -isystem by default systemwide ? may be. but we need to understand the effects where, we now more or less build host packages against our own staged headers and link/run them using the hosts libraries and this combination has been working however ugly it may look like. It also means we are using same headers across all host distros which is good but then we run the host apps against the host libraries, causing another combination more than often host systems have injected bugs into tools ( e.g. cross compilers ) which have shown to exhibit on target very hard to trace issues like such have happened. Can we then just act as a fallback to provide missing headers, after system headers, it falls into same problems or ordering and while the header might be found in build sysroot, another header that this header needs may be needed from system may be some tests by removing this from build options could be tried out, native packages like qt5 and python3 should be tested since those definitely play their own games with headers. > Regards, > Jack. > > [1] > http://stackoverflow.com/questions/37218953/isystem-on-a-system-include-directory-causes-errors > [2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70129 signature.asc Description: Message signed with OpenPGP using GPGMail -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] gcc 6.1+ and isystem
On 08/30/2016 11:37 AM, 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. I think this issue is casuing me trouble building GNU Radio with qt5 support also. I'll try and verify this. I never did figure out where the -isystem came from. Thanks for the email Jack! Philip > > Regards, > Jack. > > [1] > http://stackoverflow.com/questions/37218953/isystem-on-a-system-include-directory-causes-errors > > [2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70129 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] gcc 6.1+ and isystem
On Tue, Aug 30, 2016 at 7:00 PM, Richard Purdie 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 Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] gcc 6.1+ and isystem
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. 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... Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] gcc 6.1+ and isystem
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. Regards, Jack. [1] http://stackoverflow.com/questions/37218953/isystem-on-a-system-include-directory-causes-errors [2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70129 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
