[poky] about ${KERNEL_CC} and ${CC}

Tian, Kevin kevin.tian at intel.com
Thu Dec 23 17:01:54 PST 2010


>From: Gary Thomas [mailto:gary at mlbassoc.com]
>Sent: Thursday, December 23, 2010 8:27 PM
>
>On 12/23/2010 02:44 AM, Richard Purdie wrote:
>> On Thu, 2010-12-23 at 14:11 +0800, Tian, Kevin wrote:
>>> I'm a bit confused why a specific ${KERNEL_CC} is introduced instead of
>>> reusing ${CC}, especially when two are defined differently:
>>>
>>> <kernel.bbclass>
>>> KERNEL_CC = "${CCACHE}${HOST_PREFIX}gcc${KERNEL_CCSUFFIX}
>${HOST_CC_KERNEL_ARCH}"
>>>
>>> <bitbake.conf>
>>> export CC = "${CCACHE}${HOST_PREFIX}gcc
>${HOST_CC_ARCH}${TOOLCHAIN_OPTIONS}"
>>> TOOLCHAIN_OPTIONS = " --sysroot=${STAGING_DIR_TARGET}"
>>>
>>> I'm not sure whether kernel build requires "--sysroot" option, but it looks that it works
>well
>>> so far even without that option (why?)
>>
>> The kernel doesn't link against system libraries or use system header
>> files so it really doesn't matter whether it sees the sysroot or not.

I thought about that point, but didn't realize no dependency at all. :-)

>>
>> We use a different CC for the kernel so the user has the option of using
>> a different compiler version for this. Whilst its a lot less common now,
>> there were once use cases where the kernel would be compiled with one
>> version of gcc and the userspace with a different version.

Good to know that.

>>
>>> However this causes one issue under sstate, if the whole toolchain is installed from
>sstate
>>> packages which are built from another machine. In such case the default path (decided
>at
>>> compilation time) of gcc also points to the path on another machine, which is missing
>in
>>> current machine doing build. Perf compilation is:
>>>
>>> do_compile_perf() {
>>>          oe_runmake -C ${S}/tools/perf CC="${KERNEL_CC}" LD="${KERNEL_LD}"
>prefix=${prefix}
>>> }
>>>
>>> Without an explicit "--sysroot" options, perf compilation is broken due to failing to check
>some
>>> header files like gnu/libc-version.h. I can workaround it by:
>>>
>>> do_compile_perf() {
>>>          oe_runmake -C ${S}/tools/perf CC="${CC}" LD="${LD}" AR="${AR}"
>prefix=${prefix}
>>> }
>>
>> Perf should be compiled with the userspace toolchain, not the kernel
>> one. I'd say this fix is therefore correct.
>>
>> Adding TOOLCHAIN_OPTIONS to KERNEL_CC would also probably be a good idea
>> too.
>
>Perfect idea!  I added this and I'm now able to rebuild my
>kernel package using a sstate-cache based toolchain.  This
>should close bug #605
>
>Patch attached for review.
>

It's good to know that this fix solves your problem. So your own kernel adds some
new bits depending on system libraries like libgcc.so, does it?

BTW, if you could try some simple experiments like what I asked earlier (try normal 
yocto kernel, or try other recipes), your issue can be narrowed down earlier...
Fortunately here I encountered a similar issue on perf. :-)

Thanks
Kevin



More information about the poky mailing list