[OE-core] [PATCH 4/8] [linux-yocto] allow overriding compiler name in KConfig
Jérémy Rosen
jeremy.rosen at smile.fr
Tue Aug 23 13:48:37 UTC 2016
On 23/08/2016 15:41, Bruce Ashfield wrote:
>
>
> On Tue, Aug 23, 2016 at 9:36 AM, Bruce Ashfield
> <bruce.ashfield at gmail.com <mailto:bruce.ashfield at gmail.com>> wrote:
>
> On Tue, Aug 23, 2016 at 3:25 AM, Jérémy Rosen
> <jeremy.rosen at smile.fr <mailto:jeremy.rosen at smile.fr>> wrote:
>
> The KConfig infrastructure hardwires the compiler name to gcc,
> which breaks
> the BUILD_CC feature. This is needed even when cross compiling
> because
> make *config rely on the kconfig infrastructure
>
>
> Can you elaborate ? I'm not aware of any issues with either the
> host builds or
> target builds with the kernel.
>
>
> Aha. I found the 0/N for the series.
>
> And my answer is still the same. These belong upstream, and since the
> kernel is fairly
> picky about the compiler and compiler versions, I don't see a pressing
> need to carry
> something like this until it makes it into the mainline kernel.
>
> My answer to 'can't assume the name of gcc', is to make sure that your
> environment
> and path is fully understood, and make your compiler available as
> 'gcc', versus trying
> to patch multiple recipes.
Ok, my 0/N maybe was not as clear as I hoped. I don't want to compile
without a gcc binary. I want to make sure that when I set BUILD_* to a
specific version of gcc (gcc-5 in my case) only that version of the
compiler can be used.
As pointed, jethro can only be compiled on a machine where the default
compiler is gcc-5. Having gcc-5 installed is not enough, it needs to be
default. The BUILD_* feature was meant to prevent that, i'm just fixing it
As I have stated elsewhere, I am upstreaming the patches in parlallel
(only the glibc patch is left at this point, since I found a way to drop
the kconfig ones) hopefully I will be able to add the "submitted
upstream" tag on V2.
In the meantime, I mainly wanted comments on the approch and I was
wondering how to makes sure some sort of autmated QA test could detect
that sort of problems.
Hope this helps
Jeremy
>
> Cheers,
>
> Bruce
>
>
> If there's an issue, we need to fix it upstream .. not here.
>
> ---
> meta/recipes-kernel/linux/linux-yocto.inc | 4 ++++
> meta/recipes-kernel/linux/linux-yocto/0001-Allow-overriding-host-compiler-name-from-environment.patch
> | 32 ++++++++++++++++++++++++++++++++
> 2 files changed, 36 insertions(+), 0 deletions(-)
> create mode 100644
> meta/recipes-kernel/linux/linux-yocto/0001-Allow-overriding-host-compiler-name-from-environment.patch
>
> diff --git a/meta/recipes-kernel/linux/linux-yocto.inc
> b/meta/recipes-kernel/linux/linux-yocto.inc
> index 98a48ec..63c1531 100644
> --- a/meta/recipes-kernel/linux/linux-yocto.inc
> +++ b/meta/recipes-kernel/linux/linux-yocto.inc
> @@ -58,3 +58,7 @@ do_install_append(){
> addtask kernel_link_images after do_compile before do_install
> addtask validate_branches before do_patch after
> do_kernel_checkout
> addtask kernel_configcheck after do_configure before do_compile
> +
> +SRC_URI_append = "
> file://0001-Allow-overriding-host-compiler-name-from-environment.patch"
>
>
> We don't carry patches to linux-yocto like this, they are sent to
> the linux-yocto mailing list, and
> integrated into the tree itself.
>
> Bruce
>
> +export HOSTCC = "${BUILD_CC}"
> +export HOSTCXX = "${BUILD_CXX}"
> diff --git
> a/meta/recipes-kernel/linux/linux-yocto/0001-Allow-overriding-host-compiler-name-from-environment.patch
> b/meta/recipes-kernel/linux/linux-
>
> yocto/0001-Allow-overriding-host-compiler-name-from-environment.patch
> new file mode 100644
> index 0000000..6fcfbc8
> --- /dev/null
> +++
> b/meta/recipes-kernel/linux/linux-yocto/0001-Allow-overriding-host-compiler-name-from-environment.patch
> @@ -0,0 +1,32 @@
> +From 0ce4c4f29b5d456a7707e870c7affe524f7c8807 Mon Sep 17
> 00:00:00 2001
> +From: =?UTF-8?q?J=C3=A9r=C3=A9my=20Rosen?=
> <jeremy.rosen at smile.fr <mailto:jeremy.rosen at smile.fr>>
> +Date: Tue, 16 Aug 2016 22:39:29 +0200
> +Subject: [PATCH] Allow overriding host-compiler name from
> environment
> + variables
> +
> +---
> + Makefile | 8 ++++----
> + 1 file changed, 4 insertions(+), 4 deletions(-)
> +
> +diff --git a/Makefile b/Makefile
> +index 70dea02..1f0d2d2 100644
> +--- a/Makefile
> ++++ b/Makefile
> +@@ -295,10 +295,10 @@ CONFIG_SHELL := $(shell if [ -x
> "$$BASH" ]; then echo $$BASH; \
> + else if [ -x /bin/bash ]; then echo /bin/bash; \
> + else echo sh; fi ; fi)
> +
> +-HOSTCC = gcc
> +-HOSTCXX = g++
> +-HOSTCFLAGS = -Wall -Wmissing-prototypes
> -Wstrict-prototypes -O2 -fomit-frame-pointer -std=gnu89
> +-HOSTCXXFLAGS = -O2
> ++HOSTCC ?= gcc
> ++HOSTCXX ?= g++
> ++HOSTCFLAGS ?= -Wall -Wmissing-prototypes
> -Wstrict-prototypes -O2 -fomit-frame-pointer -std=gnu89
> ++HOSTCXXFLAGS ?= -O2
> +
> + ifeq ($(shell $(HOSTCC) -v 2>&1 | grep -c "clang version"), 1)
> + HOSTCFLAGS += -Wno-unused-value -Wno-unused-parameter \
> +--
> +2.8.1
> +
> --
> git-series 0.8.9
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core at lists.openembedded.org
> <mailto:Openembedded-core at lists.openembedded.org>
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
> <http://lists.openembedded.org/mailman/listinfo/openembedded-core>
>
>
>
>
> --
> "Thou shalt not follow the NULL pointer, for chaos and madness
> await thee at its end"
>
>
>
>
> --
> "Thou shalt not follow the NULL pointer, for chaos and madness await
> thee at its end"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20160823/23750ef8/attachment-0002.html>
More information about the Openembedded-core
mailing list