[OE-core] [PATCH] gcc: make sure header path is set correctly

Khem Raj raj.khem at gmail.com
Thu Jun 16 14:34:18 UTC 2016


> On Jun 15, 2016, at 10:49 PM, Mittal, AnujX <anujx.mittal at intel.com> wrote:
> 
> 
> 
>> -----Original Message-----
>> From: Khem Raj [mailto:raj.khem at gmail.com]
>> Sent: Thursday, June 16, 2016 10:47 AM
>> To: Mittal, AnujX <anujx.mittal at intel.com>
>> Cc: openembedded-core at 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.mittal at 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 204 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20160616/11c596a5/attachment-0002.sig>


More information about the Openembedded-core mailing list