gcc 6.1+ and isystem

gcc 6.1+ and isystem

[Jack Mitchell]

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

Re: gcc 6.1+ and isystem

[Richard Purdie]

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

Re: gcc 6.1+ and isystem

[Andreas Müller]

On Tue, Aug 30, 2016 at 7:00 PM, Richard Purdie
<richard.purdie@linuxfoundation.org> 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

Re: gcc 6.1+ and isystem

[Philip Balister]

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

Re: gcc 6.1+ and isystem

[Khem Raj]

[-- Attachment #1: Type: text/plain, Size: 2518 bytes --]


> On Aug 30, 2016, at 8:37 AM, Jack Mitchell <ml@embed.me.uk> 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


[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 211 bytes --]