summaryrefslogtreecommitdiffstats
path: root/meta/recipes-devtools/gcc/gcc-configure-common.inc
diff options
context:
space:
mode:
authorKevin Tian <kevin.tian@intel.com>2010-09-29 08:54:33 +0800
committerSaul Wold <Saul.Wold@intel.com>2010-09-30 10:18:00 -0700
commit2a066e7ca90a28d5681c5fa895a29e999ed7c88b (patch)
tree552919ae32fd247a8dde876242ca029317c69065 /meta/recipes-devtools/gcc/gcc-configure-common.inc
parentb07cc5a74abb93862f13191cd15d4aa3e1205079 (diff)
downloadopenembedded-core-2a066e7ca90a28d5681c5fa895a29e999ed7c88b.tar.gz
openembedded-core-2a066e7ca90a28d5681c5fa895a29e999ed7c88b.tar.bz2
openembedded-core-2a066e7ca90a28d5681c5fa895a29e999ed7c88b.zip
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>
Diffstat (limited to 'meta/recipes-devtools/gcc/gcc-configure-common.inc')
-rw-r--r--meta/recipes-devtools/gcc/gcc-configure-common.inc4
1 files changed, 4 insertions, 0 deletions
diff --git a/meta/recipes-devtools/gcc/gcc-configure-common.inc b/meta/recipes-devtools/gcc/gcc-configure-common.inc
index 9dd8feef7c..43937778f1 100644
--- a/meta/recipes-devtools/gcc/gcc-configure-common.inc
+++ b/meta/recipes-devtools/gcc/gcc-configure-common.inc
@@ -87,6 +87,10 @@ do_configure () {
export ARCH_FLAGS_FOR_TARGET="${ARCH_FLAGS_FOR_TARGET}"
(cd ${S} && gnu-configize) || die "failure running gnu-configize"
+ # teach gcc to find correct target includedir when checking libc ssp support
+ sed -i 's:^\([ ]*\)glibc_header_dir=\"${with_build_sysroot}/usr/include\":\1glibc_header_dir=\"${with_build_sysroot}${SYSTEMHEADERS}\":g' ${S}/gcc/configure.ac
+ sed -i 's:^\([ ]*\)glibc_header_dir=\"${with_build_sysroot}/usr/include\":\1glibc_header_dir=\"${with_build_sysroot}${SYSTEMHEADERS}\":g' ${S}/gcc/configure
+
# splice our idea of where the headers live into gcc's world
echo "NATIVE_SYSTEM_HEADER_DIR = ${SYSTEMHEADERS}" > ${T}/t-oe
sed 's%^tmake_file=.*$%& ${T}/t-oe%' < ${S}/gcc/Makefile.in >${S}/gcc/Makefile.in.new