> On Aug 30, 2016, at 8:37 AM, Jack Mitchell <[email protected]> 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 [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
