Patchwork [1/4] kernel.bbclass, module-base.bbclass: Use CC to form KERNEL_CC

login
register
mail settings
Submitter Khem Raj
Date Jan. 19, 2013, 10:40 p.m.
Message ID <613da782b369ba5424b5619b4315ea34e645d53c.1358634922.git.raj.khem@gmail.com>
Download mbox | patch
Permalink /patch/42921/
State Accepted
Commit a3ca06c3b45c791dd38dbf154ad0fc62b4063475
Headers show

Comments

Khem Raj - Jan. 19, 2013, 10:40 p.m.
kernel compiler is not special and we currently have it so
we want to pass -march and -mtune options as CFLAGS to kernel
build so that compiler picks the right subarch flags when
compiling assembly files in particular. Otherwise defaults
are chosen which may not be right in many case e.g. when
compiling kernel for collie machine we should use arch=armv4
but it uses toolchain/as defaults which is armv5te

in some case e.g. thumb1 we know that kernel can not be compiled
in thumb1 mode so we can provide that information e.g. -marm
option through KERNEL_HOST_CC_ARCH variable as we do now

Signed-off-by: Khem Raj <raj.khem@gmail.com>
---
 meta/classes/kernel-arch.bbclass |   13 +++++++++++++
 meta/classes/kernel.bbclass      |   16 +---------------
 meta/classes/module-base.bbclass |   16 ----------------
 3 files changed, 14 insertions(+), 31 deletions(-)
Enrico Scholz - Jan. 22, 2013, 3:41 p.m.
Khem Raj <raj.khem-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:

> +KERNEL_LD = "${LD} ${HOST_LD_KERNEL_ARCH}"
> ...
> -KERNEL_LD = "${HOST_PREFIX}ld${KERNEL_LDSUFFIX} ${HOST_LD_KERNEL_ARCH}${TOOLCHAIN_OPTIONS}"

that's bad... gold linker has serious problems to compile stuff like
kernel or bootloaders and setting 'KERNEL_LDSUFFIX = .bfd' was a good
way to workaround these problems.



Enrico
Khem Raj - Jan. 22, 2013, 4:33 p.m.
On 1/22/13 7:41 AM, Enrico Scholz wrote:
> Khem Raj <raj.khem-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:
>
>> +KERNEL_LD = "${LD} ${HOST_LD_KERNEL_ARCH}"
>> ...
>> -KERNEL_LD = "${HOST_PREFIX}ld${KERNEL_LDSUFFIX} ${HOST_LD_KERNEL_ARCH}${TOOLCHAIN_OPTIONS}"
>
> that's bad... gold linker has serious problems to compile stuff like
> kernel or bootloaders and setting 'KERNEL_LDSUFFIX = .bfd' was a good
> way to workaround these problems.
>

This was not the intended use of KERNEL_LD IMO.
There are is than kernel that does not go well when using gold, I think 
the right approach would be to check ld-is-gold being present in 
DISTRO_FEATURES and appending '.bfd' to LD variable like other recipes do

>
>
> Enrico
>
Khem Raj - Jan. 22, 2013, 5:34 p.m.
On 1/22/13 7:41 AM, Enrico Scholz wrote:
> Khem Raj <raj.khem-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:
>
>> +KERNEL_LD = "${LD} ${HOST_LD_KERNEL_ARCH}"
>> ...
>> -KERNEL_LD = "${HOST_PREFIX}ld${KERNEL_LDSUFFIX} ${HOST_LD_KERNEL_ARCH}${TOOLCHAIN_OPTIONS}"
>
> that's bad... gold linker has serious problems to compile stuff like
> kernel or bootloaders and setting 'KERNEL_LDSUFFIX = .bfd' was a good
> way to workaround these problems.
>

something like this patch here

http://git.openembedded.org/openembedded-core-contrib/commit/?h=kraj/misc&id=70b3efc5fc4b31f8ad17c23e77e80cb6abcac258

should work for you. Can you try it out ?

>
>
> Enrico
>
Darren Hart - Jan. 22, 2013, 8:44 p.m.
On 01/19/2013 02:40 PM, Khem Raj wrote:
> kernel compiler is not special and we currently have it so
> we want to pass -march and -mtune options as CFLAGS to kernel
> build so that compiler picks the right subarch flags when
> compiling assembly files in particular. Otherwise defaults
> are chosen which may not be right in many case e.g. when
> compiling kernel for collie machine we should use arch=armv4
> but it uses toolchain/as defaults which is armv5te
> 
> in some case e.g. thumb1 we know that kernel can not be compiled
> in thumb1 mode so we can provide that information e.g. -marm
> option through KERNEL_HOST_CC_ARCH variable as we do now
> 

Makes me nervous... only because I'm not well versed enough across the
architectures to catch some little gotchas. How much testing has this
seen? Which architectures?

--
Darren

> Signed-off-by: Khem Raj <raj.khem@gmail.com>
> ---
>  meta/classes/kernel-arch.bbclass |   13 +++++++++++++
>  meta/classes/kernel.bbclass      |   16 +---------------
>  meta/classes/module-base.bbclass |   16 ----------------
>  3 files changed, 14 insertions(+), 31 deletions(-)
> 
> diff --git a/meta/classes/kernel-arch.bbclass b/meta/classes/kernel-arch.bbclass
> index b3b78b6..a51e82b 100644
> --- a/meta/classes/kernel-arch.bbclass
> +++ b/meta/classes/kernel-arch.bbclass
> @@ -43,3 +43,16 @@ def map_uboot_arch(a, d):
>  
>  export UBOOT_ARCH = "${@map_uboot_arch(d.getVar('ARCH', True), d)}"
>  
> +# Set TARGET_??_KERNEL_ARCH in the machine .conf to set architecture
> +# specific options necessary for building the kernel and modules.
> +TARGET_CC_KERNEL_ARCH ?= ""
> +HOST_CC_KERNEL_ARCH ?= "${TARGET_CC_KERNEL_ARCH}"
> +TARGET_LD_KERNEL_ARCH ?= ""
> +HOST_LD_KERNEL_ARCH ?= "${TARGET_LD_KERNEL_ARCH}"
> +TARGET_AR_KERNEL_ARCH ?= ""
> +HOST_AR_KERNEL_ARCH ?= "${TARGET_AR_KERNEL_ARCH}"
> +
> +KERNEL_CC = "${CC} ${HOST_CC_KERNEL_ARCH}"
> +KERNEL_LD = "${LD} ${HOST_LD_KERNEL_ARCH}"
> +KERNEL_AR = "${AR} ${HOST_AR_KERNEL_ARCH}"
> +
> diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
> index d459569..e2a582b 100644
> --- a/meta/classes/kernel.bbclass
> +++ b/meta/classes/kernel.bbclass
> @@ -1,7 +1,7 @@
>  inherit linux-kernel-base module_strip
>  
>  PROVIDES += "virtual/kernel"
> -DEPENDS += "virtual/${TARGET_PREFIX}gcc kmod-native virtual/${TARGET_PREFIX}gcc${KERNEL_CCSUFFIX}"
> +DEPENDS += "virtual/${TARGET_PREFIX}gcc kmod-native"
>  
>  # we include gcc above, we dont need virtual/libc
>  INHIBIT_DEFAULT_DEPS = "1"
> @@ -37,20 +37,6 @@ KERNEL_PRIORITY ?= "${@int(d.getVar('PV',1).split('-')[0].split('+')[0].split('.
>  
>  KERNEL_RELEASE ?= "${KERNEL_VERSION}"
>  
> -KERNEL_CCSUFFIX ?= ""
> -KERNEL_LDSUFFIX ?= ""
> -
> -# Set TARGET_??_KERNEL_ARCH in the machine .conf to set architecture
> -# specific options necessary for building the kernel and modules.
> -#FIXME: should be this: TARGET_CC_KERNEL_ARCH ?= "${TARGET_CC_ARCH}"
> -TARGET_CC_KERNEL_ARCH ?= ""
> -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}${TOOLCHAIN_OPTIONS}"
> -KERNEL_LD = "${HOST_PREFIX}ld${KERNEL_LDSUFFIX} ${HOST_LD_KERNEL_ARCH}${TOOLCHAIN_OPTIONS}"
> -
>  # Where built kernel lies in the kernel tree
>  KERNEL_OUTPUT ?= "arch/${ARCH}/boot/${KERNEL_IMAGETYPE}"
>  KERNEL_IMAGEDEST = "boot"
> diff --git a/meta/classes/module-base.bbclass b/meta/classes/module-base.bbclass
> index 210c47c..cfee50a 100644
> --- a/meta/classes/module-base.bbclass
> +++ b/meta/classes/module-base.bbclass
> @@ -7,22 +7,6 @@ export CROSS_COMPILE = "${TARGET_PREFIX}"
>  
>  export KERNEL_VERSION = "${@base_read_file('${STAGING_KERNEL_DIR}/kernel-abiversion')}"
>  KERNEL_OBJECT_SUFFIX = ".ko"
> -KERNEL_CCSUFFIX = "${@base_read_file('${STAGING_KERNEL_DIR}/kernel-ccsuffix')}"
> -KERNEL_LDSUFFIX = "${@base_read_file('${STAGING_KERNEL_DIR}/kernel-ldsuffix')}"
> -KERNEL_ARSUFFIX = "${@base_read_file('${STAGING_KERNEL_DIR}/kernel-arsuffix')}"
> -
> -# Set TARGET_??_KERNEL_ARCH in the machine .conf to set architecture
> -# specific options necessary for building the kernel and modules.
> -TARGET_CC_KERNEL_ARCH ?= ""
> -HOST_CC_KERNEL_ARCH ?= "${TARGET_CC_KERNEL_ARCH}"
> -TARGET_LD_KERNEL_ARCH ?= ""
> -HOST_LD_KERNEL_ARCH ?= "${TARGET_LD_KERNEL_ARCH}"
> -TARGET_AR_KERNEL_ARCH ?= ""
> -HOST_AR_KERNEL_ARCH ?= "${TARGET_AR_KERNEL_ARCH}"
> -
> -KERNEL_CC = "${CCACHE}${HOST_PREFIX}gcc${KERNEL_CCSUFFIX} ${HOST_CC_KERNEL_ARCH}"
> -KERNEL_LD = "${HOST_PREFIX}ld${KERNEL_LDSUFFIX} ${HOST_LD_KERNEL_ARCH}"
> -KERNEL_AR = "${HOST_PREFIX}ar${KERNEL_ARSUFFIX} ${HOST_AR_KERNEL_ARCH}"
>  
>  # kernel modules are generally machine specific
>  PACKAGE_ARCH = "${MACHINE_ARCH}"
>
Khem Raj - Jan. 22, 2013, 9:44 p.m.
On Tue, Jan 22, 2013 at 12:44 PM, Darren Hart <dvhart@linux.intel.com> wrote:
>
> Makes me nervous... only because I'm not well versed enough across the
> architectures to catch some little gotchas. How much testing has this
> seen? Which architectures?

little but then I did not propose it for inclusion into master yet so
why worry ?
Darren Hart - Jan. 22, 2013, 9:50 p.m.
On 01/22/2013 01:44 PM, Khem Raj wrote:
> On Tue, Jan 22, 2013 at 12:44 PM, Darren Hart <dvhart@linux.intel.com> wrote:
>>
>> Makes me nervous... only because I'm not well versed enough across the
>> architectures to catch some little gotchas. How much testing has this
>> seen? Which architectures?
> 
> little but then I did not propose it for inclusion into master yet so
> why worry ?

I assumed that would be the target eventually - is that not the case?
Khem Raj - Jan. 22, 2013, 10:12 p.m.
On Tue, Jan 22, 2013 at 1:50 PM, Darren Hart <dvhart@linux.intel.com> wrote:
> I assumed that would be the target eventually - is that not the case?

yes when we have tested it
However, I don’t see any other better way of coping with the case where we
would like to use gold as default linker distrowide. One could cook up
a patch for kernel
to demand ld.bfd always like I did for uboot but we have way too many kernels
to patch. I am open for other suggestions.
Darren Hart - Jan. 22, 2013, 10:19 p.m.
On 01/22/2013 02:12 PM, Khem Raj wrote:
> On Tue, Jan 22, 2013 at 1:50 PM, Darren Hart <dvhart@linux.intel.com> wrote:
>> I assumed that would be the target eventually - is that not the case?
> 
> yes when we have tested it
> However, I don’t see any other better way of coping with the case where we
> would like to use gold as default linker distrowide. One could cook up
> a patch for kernel
> to demand ld.bfd always like I did for uboot but we have way too many kernels
> to patch. I am open for other suggestions.
> 

I don't object to the approach, I was just wanting to boost my
confidence level with testing results. Sounds like that's coming, and I
should probably do some runs myself.
Andrea Adami - Jan. 23, 2013, 8:46 a.m.
On Tue, Jan 22, 2013 at 9:44 PM, Darren Hart <dvhart@linux.intel.com> wrote:
>
>
> On 01/19/2013 02:40 PM, Khem Raj wrote:
>> kernel compiler is not special and we currently have it so
>> we want to pass -march and -mtune options as CFLAGS to kernel
>> build so that compiler picks the right subarch flags when
>> compiling assembly files in particular. Otherwise defaults
>> are chosen which may not be right in many case e.g. when
>> compiling kernel for collie machine we should use arch=armv4
>> but it uses toolchain/as defaults which is armv5te
>>
>> in some case e.g. thumb1 we know that kernel can not be compiled
>> in thumb1 mode so we can provide that information e.g. -marm
>> option through KERNEL_HOST_CC_ARCH variable as we do now
>>
>
> Makes me nervous... only because I'm not well versed enough across the
> architectures to catch some little gotchas. How much testing has this
> seen? Which architectures?
>

I've built and booted kernels for strongarm/armv4) and for pxa/armv5te.


Andrea



> --
> Darren
>
>> Signed-off-by: Khem Raj <raj.khem@gmail.com>
>> ---
>>  meta/classes/kernel-arch.bbclass |   13 +++++++++++++
>>  meta/classes/kernel.bbclass      |   16 +---------------
>>  meta/classes/module-base.bbclass |   16 ----------------
>>  3 files changed, 14 insertions(+), 31 deletions(-)
>>
>> diff --git a/meta/classes/kernel-arch.bbclass b/meta/classes/kernel-arch.bbclass
>> index b3b78b6..a51e82b 100644
>> --- a/meta/classes/kernel-arch.bbclass
>> +++ b/meta/classes/kernel-arch.bbclass
>> @@ -43,3 +43,16 @@ def map_uboot_arch(a, d):
>>
>>  export UBOOT_ARCH = "${@map_uboot_arch(d.getVar('ARCH', True), d)}"
>>
>> +# Set TARGET_??_KERNEL_ARCH in the machine .conf to set architecture
>> +# specific options necessary for building the kernel and modules.
>> +TARGET_CC_KERNEL_ARCH ?= ""
>> +HOST_CC_KERNEL_ARCH ?= "${TARGET_CC_KERNEL_ARCH}"
>> +TARGET_LD_KERNEL_ARCH ?= ""
>> +HOST_LD_KERNEL_ARCH ?= "${TARGET_LD_KERNEL_ARCH}"
>> +TARGET_AR_KERNEL_ARCH ?= ""
>> +HOST_AR_KERNEL_ARCH ?= "${TARGET_AR_KERNEL_ARCH}"
>> +
>> +KERNEL_CC = "${CC} ${HOST_CC_KERNEL_ARCH}"
>> +KERNEL_LD = "${LD} ${HOST_LD_KERNEL_ARCH}"
>> +KERNEL_AR = "${AR} ${HOST_AR_KERNEL_ARCH}"
>> +
>> diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
>> index d459569..e2a582b 100644
>> --- a/meta/classes/kernel.bbclass
>> +++ b/meta/classes/kernel.bbclass
>> @@ -1,7 +1,7 @@
>>  inherit linux-kernel-base module_strip
>>
>>  PROVIDES += "virtual/kernel"
>> -DEPENDS += "virtual/${TARGET_PREFIX}gcc kmod-native virtual/${TARGET_PREFIX}gcc${KERNEL_CCSUFFIX}"
>> +DEPENDS += "virtual/${TARGET_PREFIX}gcc kmod-native"
>>
>>  # we include gcc above, we dont need virtual/libc
>>  INHIBIT_DEFAULT_DEPS = "1"
>> @@ -37,20 +37,6 @@ KERNEL_PRIORITY ?= "${@int(d.getVar('PV',1).split('-')[0].split('+')[0].split('.
>>
>>  KERNEL_RELEASE ?= "${KERNEL_VERSION}"
>>
>> -KERNEL_CCSUFFIX ?= ""
>> -KERNEL_LDSUFFIX ?= ""
>> -
>> -# Set TARGET_??_KERNEL_ARCH in the machine .conf to set architecture
>> -# specific options necessary for building the kernel and modules.
>> -#FIXME: should be this: TARGET_CC_KERNEL_ARCH ?= "${TARGET_CC_ARCH}"
>> -TARGET_CC_KERNEL_ARCH ?= ""
>> -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}${TOOLCHAIN_OPTIONS}"
>> -KERNEL_LD = "${HOST_PREFIX}ld${KERNEL_LDSUFFIX} ${HOST_LD_KERNEL_ARCH}${TOOLCHAIN_OPTIONS}"
>> -
>>  # Where built kernel lies in the kernel tree
>>  KERNEL_OUTPUT ?= "arch/${ARCH}/boot/${KERNEL_IMAGETYPE}"
>>  KERNEL_IMAGEDEST = "boot"
>> diff --git a/meta/classes/module-base.bbclass b/meta/classes/module-base.bbclass
>> index 210c47c..cfee50a 100644
>> --- a/meta/classes/module-base.bbclass
>> +++ b/meta/classes/module-base.bbclass
>> @@ -7,22 +7,6 @@ export CROSS_COMPILE = "${TARGET_PREFIX}"
>>
>>  export KERNEL_VERSION = "${@base_read_file('${STAGING_KERNEL_DIR}/kernel-abiversion')}"
>>  KERNEL_OBJECT_SUFFIX = ".ko"
>> -KERNEL_CCSUFFIX = "${@base_read_file('${STAGING_KERNEL_DIR}/kernel-ccsuffix')}"
>> -KERNEL_LDSUFFIX = "${@base_read_file('${STAGING_KERNEL_DIR}/kernel-ldsuffix')}"
>> -KERNEL_ARSUFFIX = "${@base_read_file('${STAGING_KERNEL_DIR}/kernel-arsuffix')}"
>> -
>> -# Set TARGET_??_KERNEL_ARCH in the machine .conf to set architecture
>> -# specific options necessary for building the kernel and modules.
>> -TARGET_CC_KERNEL_ARCH ?= ""
>> -HOST_CC_KERNEL_ARCH ?= "${TARGET_CC_KERNEL_ARCH}"
>> -TARGET_LD_KERNEL_ARCH ?= ""
>> -HOST_LD_KERNEL_ARCH ?= "${TARGET_LD_KERNEL_ARCH}"
>> -TARGET_AR_KERNEL_ARCH ?= ""
>> -HOST_AR_KERNEL_ARCH ?= "${TARGET_AR_KERNEL_ARCH}"
>> -
>> -KERNEL_CC = "${CCACHE}${HOST_PREFIX}gcc${KERNEL_CCSUFFIX} ${HOST_CC_KERNEL_ARCH}"
>> -KERNEL_LD = "${HOST_PREFIX}ld${KERNEL_LDSUFFIX} ${HOST_LD_KERNEL_ARCH}"
>> -KERNEL_AR = "${HOST_PREFIX}ar${KERNEL_ARSUFFIX} ${HOST_AR_KERNEL_ARCH}"
>>
>>  # kernel modules are generally machine specific
>>  PACKAGE_ARCH = "${MACHINE_ARCH}"
>>
>
> --
> Darren Hart
> Intel Open Source Technology Center
> Yocto Project - Technical Lead - Linux Kernel
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Enrico Scholz - Jan. 24, 2013, 12:13 p.m.
Khem Raj <raj.khem-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:

>>> +KERNEL_LD = "${LD} ${HOST_LD_KERNEL_ARCH}"
>>> ...
>>> -KERNEL_LD = "${HOST_PREFIX}ld${KERNEL_LDSUFFIX} ${HOST_LD_KERNEL_ARCH}${TOOLCHAIN_OPTIONS}"
>>
>> that's bad... gold linker has serious problems to compile stuff like
>> kernel or bootloaders and setting 'KERNEL_LDSUFFIX = .bfd' was a good
>> way to workaround these problems.
>>
>
> This was not the intended use of KERNEL_LD IMO.

ok; then I abused it for this purpose and stuff failed more or less
silently with recent oe ;)

Me wonders whether we should implement a more generic way to select
between .bfd and .gold linker.  Overriding LD works well when LD is used
by the build system, but when it is called through gcc -> collect there
is no way to select the linker.

For grub2 I use

------
PATH_prepend = "${S}/.bin:"
CC_prepend = "env COMPILER_PATH=${S}/.bin/gcc "

do_configure_prepend() {
    mkdir -p .bin/gcc
    { echo "#!/bin/sh"
      echo 'exec ${TARGET_PREFIX}ld.bfd "$@"'
    } > .bin/${TARGET_PREFIX}ld
    chmod +x .bin/${TARGET_PREFIX}ld
    ln -s ../${TARGET_PREFIX}ld .bin/gcc/ld
}
------

which might go into a more general .bbclass.

Modifying binutils or gcc to select the wanted linker is probably the
2nd best solution (after fixing gold linker). E.g. for binutils, the
'arm-linux-gnueabi-ld' binary (or however it is called) which is a copy
of .bfd or .gold atm can be replaced by a oe specific program which
calls the corresponding linker depending on an environment variable.

Changing gcc seems to be more difficultly because name of ld is determined
at multiple locations.

So we have to following options:

1. keep things as is; when problems with gold arise[1], people have to turn
   it of globally

2. create a 'custom-ld.bbclass' which is inherited on demand

3. create custom 'ld' program evaluating '${OE_LDSUFFIX}' which is set
   on demand

4. patch gcc/collect to call a linker specified by environment


I favor 3; what do you think?



Enrico

Footnotes: 
[1]  I am aware of
     * kernel (--> '--march=all' object file mismatch)
     * barebox (--> optimizing away constructors with '--gc-shared')
     * grub2 (--> disfunctional with gold; no further details)
McClintock Matthew-B29882 - Feb. 4, 2013, 8:13 p.m.
On Sat, Jan 19, 2013 at 4:40 PM, Khem Raj <raj.khem@gmail.com> wrote:
> kernel compiler is not special and we currently have it so
> we want to pass -march and -mtune options as CFLAGS to kernel
> build so that compiler picks the right subarch flags when
> compiling assembly files in particular. Otherwise defaults
> are chosen which may not be right in many case e.g. when
> compiling kernel for collie machine we should use arch=armv4
> but it uses toolchain/as defaults which is armv5te
>
> in some case e.g. thumb1 we know that kernel can not be compiled
> in thumb1 mode so we can provide that information e.g. -marm
> option through KERNEL_HOST_CC_ARCH variable as we do now
>
> Signed-off-by: Khem Raj <raj.khem@gmail.com>
> ---
>  meta/classes/kernel-arch.bbclass |   13 +++++++++++++
>  meta/classes/kernel.bbclass      |   16 +---------------
>  meta/classes/module-base.bbclass |   16 ----------------
>  3 files changed, 14 insertions(+), 31 deletions(-)
>
> diff --git a/meta/classes/kernel-arch.bbclass b/meta/classes/kernel-arch.bbclass
> index b3b78b6..a51e82b 100644
> --- a/meta/classes/kernel-arch.bbclass
> +++ b/meta/classes/kernel-arch.bbclass
> @@ -43,3 +43,16 @@ def map_uboot_arch(a, d):
>
>  export UBOOT_ARCH = "${@map_uboot_arch(d.getVar('ARCH', True), d)}"
>
> +# Set TARGET_??_KERNEL_ARCH in the machine .conf to set architecture
> +# specific options necessary for building the kernel and modules.
> +TARGET_CC_KERNEL_ARCH ?= ""
> +HOST_CC_KERNEL_ARCH ?= "${TARGET_CC_KERNEL_ARCH}"
> +TARGET_LD_KERNEL_ARCH ?= ""
> +HOST_LD_KERNEL_ARCH ?= "${TARGET_LD_KERNEL_ARCH}"
> +TARGET_AR_KERNEL_ARCH ?= ""
> +HOST_AR_KERNEL_ARCH ?= "${TARGET_AR_KERNEL_ARCH}"
> +
> +KERNEL_CC = "${CC} ${HOST_CC_KERNEL_ARCH}"

Why change to ${CC} from "${CCACHE}${HOST_PREFIX}gcc${KERNEL_CCSUFFIX}?

It breaks some kernel builds we have...

-M
Khem Raj - Feb. 4, 2013, 10:51 p.m.
On Mon, Feb 4, 2013 at 12:13 PM, McClintock Matthew-B29882
<B29882@freescale.com> wrote:
>> +
>> +KERNEL_CC = "${CC} ${HOST_CC_KERNEL_ARCH}"
>
> Why change to ${CC} from "${CCACHE}${HOST_PREFIX}gcc${KERNEL_CCSUFFIX}?
>
> It breaks some kernel builds we have...

you did not tell what exactly breaks.
McClintock Matthew-B29882 - Feb. 4, 2013, 11:56 p.m.
On Mon, Feb 4, 2013 at 4:51 PM, Khem Raj <raj.khem@gmail.com> wrote:
> On Mon, Feb 4, 2013 at 12:13 PM, McClintock Matthew-B29882
> <B29882@freescale.com> wrote:
>>> +
>>> +KERNEL_CC = "${CC} ${HOST_CC_KERNEL_ARCH}"
>>
>> Why change to ${CC} from "${CCACHE}${HOST_PREFIX}gcc${KERNEL_CCSUFFIX}?
>>
>> It breaks some kernel builds we have...
>
> you did not tell what exactly breaks.

Shame on me. Our kernel gets built wrong if we pass the extra -march
or -mtune to the compiler during the kernel build. It might be
exposing another issue but not sure exactly. I need to dig up a log so
I can send that over later. Here was my fix:

http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/?h=mattsm/master&id=f008446117106831585ed371453d1f052cdfd9eb

-M

Patch

diff --git a/meta/classes/kernel-arch.bbclass b/meta/classes/kernel-arch.bbclass
index b3b78b6..a51e82b 100644
--- a/meta/classes/kernel-arch.bbclass
+++ b/meta/classes/kernel-arch.bbclass
@@ -43,3 +43,16 @@  def map_uboot_arch(a, d):
 
 export UBOOT_ARCH = "${@map_uboot_arch(d.getVar('ARCH', True), d)}"
 
+# Set TARGET_??_KERNEL_ARCH in the machine .conf to set architecture
+# specific options necessary for building the kernel and modules.
+TARGET_CC_KERNEL_ARCH ?= ""
+HOST_CC_KERNEL_ARCH ?= "${TARGET_CC_KERNEL_ARCH}"
+TARGET_LD_KERNEL_ARCH ?= ""
+HOST_LD_KERNEL_ARCH ?= "${TARGET_LD_KERNEL_ARCH}"
+TARGET_AR_KERNEL_ARCH ?= ""
+HOST_AR_KERNEL_ARCH ?= "${TARGET_AR_KERNEL_ARCH}"
+
+KERNEL_CC = "${CC} ${HOST_CC_KERNEL_ARCH}"
+KERNEL_LD = "${LD} ${HOST_LD_KERNEL_ARCH}"
+KERNEL_AR = "${AR} ${HOST_AR_KERNEL_ARCH}"
+
diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index d459569..e2a582b 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -1,7 +1,7 @@ 
 inherit linux-kernel-base module_strip
 
 PROVIDES += "virtual/kernel"
-DEPENDS += "virtual/${TARGET_PREFIX}gcc kmod-native virtual/${TARGET_PREFIX}gcc${KERNEL_CCSUFFIX}"
+DEPENDS += "virtual/${TARGET_PREFIX}gcc kmod-native"
 
 # we include gcc above, we dont need virtual/libc
 INHIBIT_DEFAULT_DEPS = "1"
@@ -37,20 +37,6 @@  KERNEL_PRIORITY ?= "${@int(d.getVar('PV',1).split('-')[0].split('+')[0].split('.
 
 KERNEL_RELEASE ?= "${KERNEL_VERSION}"
 
-KERNEL_CCSUFFIX ?= ""
-KERNEL_LDSUFFIX ?= ""
-
-# Set TARGET_??_KERNEL_ARCH in the machine .conf to set architecture
-# specific options necessary for building the kernel and modules.
-#FIXME: should be this: TARGET_CC_KERNEL_ARCH ?= "${TARGET_CC_ARCH}"
-TARGET_CC_KERNEL_ARCH ?= ""
-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}${TOOLCHAIN_OPTIONS}"
-KERNEL_LD = "${HOST_PREFIX}ld${KERNEL_LDSUFFIX} ${HOST_LD_KERNEL_ARCH}${TOOLCHAIN_OPTIONS}"
-
 # Where built kernel lies in the kernel tree
 KERNEL_OUTPUT ?= "arch/${ARCH}/boot/${KERNEL_IMAGETYPE}"
 KERNEL_IMAGEDEST = "boot"
diff --git a/meta/classes/module-base.bbclass b/meta/classes/module-base.bbclass
index 210c47c..cfee50a 100644
--- a/meta/classes/module-base.bbclass
+++ b/meta/classes/module-base.bbclass
@@ -7,22 +7,6 @@  export CROSS_COMPILE = "${TARGET_PREFIX}"
 
 export KERNEL_VERSION = "${@base_read_file('${STAGING_KERNEL_DIR}/kernel-abiversion')}"
 KERNEL_OBJECT_SUFFIX = ".ko"
-KERNEL_CCSUFFIX = "${@base_read_file('${STAGING_KERNEL_DIR}/kernel-ccsuffix')}"
-KERNEL_LDSUFFIX = "${@base_read_file('${STAGING_KERNEL_DIR}/kernel-ldsuffix')}"
-KERNEL_ARSUFFIX = "${@base_read_file('${STAGING_KERNEL_DIR}/kernel-arsuffix')}"
-
-# Set TARGET_??_KERNEL_ARCH in the machine .conf to set architecture
-# specific options necessary for building the kernel and modules.
-TARGET_CC_KERNEL_ARCH ?= ""
-HOST_CC_KERNEL_ARCH ?= "${TARGET_CC_KERNEL_ARCH}"
-TARGET_LD_KERNEL_ARCH ?= ""
-HOST_LD_KERNEL_ARCH ?= "${TARGET_LD_KERNEL_ARCH}"
-TARGET_AR_KERNEL_ARCH ?= ""
-HOST_AR_KERNEL_ARCH ?= "${TARGET_AR_KERNEL_ARCH}"
-
-KERNEL_CC = "${CCACHE}${HOST_PREFIX}gcc${KERNEL_CCSUFFIX} ${HOST_CC_KERNEL_ARCH}"
-KERNEL_LD = "${HOST_PREFIX}ld${KERNEL_LDSUFFIX} ${HOST_LD_KERNEL_ARCH}"
-KERNEL_AR = "${HOST_PREFIX}ar${KERNEL_ARSUFFIX} ${HOST_AR_KERNEL_ARCH}"
 
 # kernel modules are generally machine specific
 PACKAGE_ARCH = "${MACHINE_ARCH}"