> On Jun 15, 2016, at 10:49 PM, Mittal, AnujX <anujx.mit...@intel.com> wrote: > > > >> -----Original Message----- >> From: Khem Raj [mailto:raj.k...@gmail.com] >> Sent: Thursday, June 16, 2016 10:47 AM >> To: Mittal, AnujX <anujx.mit...@intel.com> >> Cc: openembedded-core@lists.openembedded.org >> Subject: Re: [OE-core] [PATCH] gcc: make sure header path is set correctly >> >> >>> On Jun 14, 2016, at 2:10 AM, Anuj Mittal <anujx.mit...@intel.com> wrote: >>> >>> We're setting the native header paths in do_configure_prepend, >>> and don't need to set them again here. >>> >>> This results in gcc-target not being able to locate the headers >>> and not being able to detect glibc version, which in turn >>> results in SSP support not getting detected even though it's available >>> in libc. >>> >> >> what is this being set to in do_conigure_prepend ? >> that value may not be right for target recipe. For target we are setting >> sysroot to / >> and if we do not have this option set then it will set native-system-headers >> dir to >> be >> / relative and not cross sysroot relative. So it will use your build hosts >> installation >> for these headers which is not correct either. Have you looked deeper into >> why its >> not >> finding ssp support inside the cross sysroot? > > It's being set to /usr/include: > > # teach gcc to find correct target includedir when checking libc ssp > support > mkdir -p ${B}/gcc > echo "NATIVE_SYSTEM_HEADER_DIR = ${SYSTEMHEADERS}" > ${B}/gcc/t-oe > cat ${S}/gcc/defaults.h | grep -v "\#endif.*GCC_DEFAULTS_H" > > ${B}/gcc/defaults.h.new > cat >>${B}/gcc/defaults.h.new <<_EOF > #define NATIVE_SYSTEM_HEADER_DIR "${SYSTEMHEADERS}" > #define STANDARD_STARTFILE_PREFIX_1 "${SYSTEMLIBS}" > #define STANDARD_STARTFILE_PREFIX_2 "${SYSTEMLIBS1}" > #define SYSTEMLIBS_DIR "${SYSTEMLIBS}" > #endif /* ! GCC_DEFAULTS_H */ > _EOF > mv ${B}/gcc/defaults.h.new ${B}/gcc/defaults.h
ah yes thats the caveat which invalidates the definition of this configure option for OE. In this case the patch is ok. Although, I would like to know what would be downside of not forcing NATIVE_SYSTEM_HEADER_DIR via t-oe > > Having set NATIVE_SYSTEM_HEADER_DIR again in gcc-target just results in gcc > not being able to find features.h at all, which is present in the target > sysroot. > > Because it's not able to find features.h, it just assumes that glibc version > available is 0 and hence disables ssp support. Setting > NATIVE_SYSTEM_HEADER_DIR to /usr/include just makes sure that > target_system_dir in configure script is set to right header path within > target sysroot & it can pick up the right header relative to the sysroot. > > When configure option is passed, gcc detects target_system_dir (where > features.h is present) to be <build_sysroot>/<build_sysroot>/usr/include > instead of <build_sysroot>/usr/include. > > I've made sure that its picking up the header from target sysroot rather than > my host. My host machine has glibc 2.19 whereas the target sysroot has 2.22 > > Thanks, > Anuj
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
