* about ${KERNEL_CC} and ${CC}
@ 2010-12-23 6:11 Tian, Kevin
2010-12-23 9:44 ` Richard Purdie
0 siblings, 1 reply; 6+ messages in thread
From: Tian, Kevin @ 2010-12-23 6:11 UTC (permalink / raw)
To: poky@pokylinux.org
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?)
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}
}
Before going with that fix, I'd like to understand the difference between {KERNEL_CC} and
${CC} first, e.g. another option Is to simply attach TOOLCHAIN_OPTIONS to KERNEL_CC..
Thanks
Kevin
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: about ${KERNEL_CC} and ${CC}
2010-12-23 6:11 about ${KERNEL_CC} and ${CC} Tian, Kevin
@ 2010-12-23 9:44 ` Richard Purdie
2010-12-23 12:27 ` Gary Thomas
0 siblings, 1 reply; 6+ messages in thread
From: Richard Purdie @ 2010-12-23 9:44 UTC (permalink / raw)
To: Tian, Kevin; +Cc: poky@pokylinux.org
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.
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.
> 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.
Cheers,
Richard
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: about ${KERNEL_CC} and ${CC}
2010-12-23 9:44 ` Richard Purdie
@ 2010-12-23 12:27 ` Gary Thomas
2010-12-24 1:01 ` Tian, Kevin
2010-12-30 10:21 ` Richard Purdie
0 siblings, 2 replies; 6+ messages in thread
From: Gary Thomas @ 2010-12-23 12:27 UTC (permalink / raw)
To: Richard Purdie; +Cc: poky@pokylinux.org
[-- Attachment #1: Type: text/plain, Size: 2485 bytes --]
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.
>
> 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.
>
>> 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.
--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------
[-- Attachment #2: 0001-Include-sysroot-in-KERNEL_CC-allows-tools-to-move.patch --]
[-- Type: text/plain, Size: 1076 bytes --]
From 316c5f347106f4edb3d72818025916cac164d526 Mon Sep 17 00:00:00 2001
From: Gary Thomas <gary@mlbassoc.com>
Date: Thu, 23 Dec 2010 05:20:20 -0700
Subject: [PATCH] Include --sysroot in ${KERNEL_CC} - allows tools to move
Signed-off-by: Gary Thomas <gary@mlbassoc.com>
---
meta/classes/kernel.bbclass | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index 26273bd..f380a5c 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -40,7 +40,8 @@ HOST_CC_KERNEL_ARCH ?= "${TARGET_CC_KERNEL_ARCH}"
TARGET_LD_KERNEL_ARCH ?= ""
HOST_LD_KERNEL_ARCH ?= "${TARGET_LD_KERNEL_ARCH}"
-KERNEL_CC = "${CCACHE}${HOST_PREFIX}gcc${KERNEL_CCSUFFIX} ${HOST_CC_KERNEL_ARCH}"
+KERNEL_CC = "${CCACHE}${HOST_PREFIX}gcc${KERNEL_CCSUFFIX} ${HOST_CC_KERNEL_ARCH} ${TOOLCHAIN_OPTIONS}"
+TOOLCHAIN_OPTIONS = " --sysroot=${STAGING_DIR_TARGET}"
KERNEL_LD = "${LD}${KERNEL_LDSUFFIX} ${HOST_LD_KERNEL_ARCH}"
# Where built kernel lies in the kernel tree
--
1.7.2.3
^ permalink raw reply related [flat|nested] 6+ messages in thread* Re: about ${KERNEL_CC} and ${CC}
2010-12-23 12:27 ` Gary Thomas
@ 2010-12-24 1:01 ` Tian, Kevin
2010-12-30 10:21 ` Richard Purdie
1 sibling, 0 replies; 6+ messages in thread
From: Tian, Kevin @ 2010-12-24 1:01 UTC (permalink / raw)
To: Gary Thomas, Richard Purdie; +Cc: poky@pokylinux.org
>From: Gary Thomas [mailto:gary@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
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: about ${KERNEL_CC} and ${CC}
2010-12-23 12:27 ` Gary Thomas
2010-12-24 1:01 ` Tian, Kevin
@ 2010-12-30 10:21 ` Richard Purdie
2010-12-30 18:02 ` Gary Thomas
1 sibling, 1 reply; 6+ messages in thread
From: Richard Purdie @ 2010-12-30 10:21 UTC (permalink / raw)
To: Gary Thomas; +Cc: poky@pokylinux.org
On Thu, 2010-12-23 at 05:27 -0700, Gary Thomas wrote:
> On 12/23/2010 02:44 AM, Richard Purdie wrote:
> > 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.
There is no need to set TOOLCHAIN_OPTIONS and we need to alter both
KERNEL_CC and KERNEL_LD which both have this problem or
TOOLCHAIN_OPTIONS being missing. I've pushed a patch into master which
does this.
I've also pushed a patch to ensure the userspace compiler if used to
build perf.
Let me know if there are any more problems in this area.
Cheers,
Richard
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: about ${KERNEL_CC} and ${CC}
2010-12-30 10:21 ` Richard Purdie
@ 2010-12-30 18:02 ` Gary Thomas
0 siblings, 0 replies; 6+ messages in thread
From: Gary Thomas @ 2010-12-30 18:02 UTC (permalink / raw)
To: Richard Purdie; +Cc: poky@pokylinux.org
On 12/30/2010 03:21 AM, Richard Purdie wrote:
> On Thu, 2010-12-23 at 05:27 -0700, Gary Thomas wrote:
>> On 12/23/2010 02:44 AM, Richard Purdie wrote:
>>> 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.
>
> There is no need to set TOOLCHAIN_OPTIONS and we need to alter both
> KERNEL_CC and KERNEL_LD which both have this problem or
> TOOLCHAIN_OPTIONS being missing. I've pushed a patch into master which
> does this.
>
> I've also pushed a patch to ensure the userspace compiler if used to
> build perf.
>
> Let me know if there are any more problems in this area.
Thanks, this all seems to be working well now.
--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2010-12-30 18:02 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-12-23 6:11 about ${KERNEL_CC} and ${CC} Tian, Kevin
2010-12-23 9:44 ` Richard Purdie
2010-12-23 12:27 ` Gary Thomas
2010-12-24 1:01 ` Tian, Kevin
2010-12-30 10:21 ` Richard Purdie
2010-12-30 18:02 ` Gary Thomas
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.