gcc: fix check for target libc ssp support

gcc uses hardcoded path "${with-build-sysroot}/usr/include" to check target
libc ssp support. Based on GLIBC version strings in features.h in that search
path, gcc knows whether target (e)glibc implements stack protector itself.

However this breaks meta-toolchain, which actually has target libc headers
installed under {with-build-sysroot}/opt/... This way features.h is not found
and thus gcc-crosssdk-intermediate thinks that target (e)glibc doesn't support ssp.

Later when building eglibc-nativesdk, undefined reference to "__stack_chk_guard"
occurs which was caused by:

  o eglibc do_configure found that gcc-crosssdk-intermediate supports ssp,
    and thus enable -fstack-protector for nscd

  o eglibc itself supports stack smash proctection for some architectures such
    as i386, x86-64, etc. It's expected to use its own method to provide stack
    protection, instead of relying on gcc. So eglibc rtld.os doesn't export
    __stack_chk_guard to other modules

  o then when installing nscd objects, gcc-crosssdk-intermediate sees the
    flag "-fstack-protector", while it thought this eglibc doesn't implement
    ssp itself, so gcc turns to the alternative to find a valid
    __stack_chk_guard exported. eglibc doesn'g export it, while
    gcc-crosssdk-intermediate itself disables libssp.

Then the undefined reference happens. If enabling libssp for gcc-crosssdk-
intermediate, it may also work-around this issue. But the ideal fix is still
to replace hard coded path with the actual one where target libc gets installed.

glibc-nativesdk doesn't encounter this issue because it thinks gcc doesn't
support ssp, and thus doesn't enable "-fstack-protector" for nscd. Don't know
the reason yet

This fix [BUGID #366]

Signed-off-by: Dexuan Cui <dexuan.cui@intel.com>
Signed-off-by: Kevin Tian <kevin.tian@intel.com>

0 files changed, 0 insertions, 0 deletions