[PATCH 0/8] Fix BUILD_* family of variables

[PATCH 0/8] Fix BUILD_* family of variables

[Jérémy Rosen]

The BUILD_* family of variables allow the user to specify the name of the host
compiler to use at build time. This feature is particularly important for long
term maintainance. Future versions of gcc might not be compatible with old
yocto distributions and we can't assume that "gcc" is the correct name for the
compiler.

This problem is already an issue with Jethro which can't be compiled on a
machine wher gcc-6 is the default compiler. pkgconfig-native will refuse to
compile because it uses -Werror and gcc-6 has new warnings compared to gcc-5

This patch serie fixes multiple hard-coded references to gcc in various recipes
and build infrastructure

This patch was tested by building core-image-minimal for qemu-x86_64 with a
directory with the following content added to the PATH

 g++ -> /bin/false
 gcc -> /bin/false
 myg++ -> /usr/bin/g++
 mygcc -> /usr/bin/gcc

And the following variables added to local.conf

export BUILD_CC = "mygcc"
export BUILD_CXX = "myg++"
export BUILD_CPP = "mygcc -E"
export BUILD_CCLD = "mygcc"

---

All the patches haven't been pushed upstream yet, but I would be interested on
feedback on the actual work.

It would also be interesting to modify yocto's builders to use the BUILD_*
variable in order to have some early warning wrt gcc polution in recipes, but
seeing the various recipes I had to patch, I would expect such a change to
trigger a high number of build failures.

Jérémy Rosen (8):
  [autotools] export CCLD_FOR_BUILD
  [cross] export CC family from BUILD_* for cross compilers
  [rpm] force a configure before make distclean
  [linux-yocto] allow overriding compiler name in KConfig
  [linux-libc-headers] allow overriding compiler name in KConfig
  [busybox] allow overriding compiler name in KConfig
  [sanity] fix hardcoded references to gcc
  [glibc] remove hard-coded reference to gcc -E

 meta/classes/autotools.bbclass                                                                                            |  2 ++
 meta/classes/cross.bbclass                                                                                                | 12 ++++++++++++
 meta/classes/sanity.bbclass                                                                                               | 14 +++++++-------
 meta/recipes-core/busybox/busybox.inc                                                                                     |  5 +++++
 meta/recipes-core/busybox/busybox/0001-Allow-overriding-of-host-compiler-names.patch                                      | 27 +++++++++++++++++++++++++++
 meta/recipes-core/glibc/glibc/0001-locale-fix-hard-coded-reference-to-gcc-E.patch                                         | 23 +++++++++++++++++++++++
 meta/recipes-core/glibc/glibc_2.24.bb                                                                                     |  6 ++----
 meta/recipes-devtools/rpm/rpm_5.4.16.bb                                                                                   |  2 +-
 meta/recipes-kernel/linux-libc-headers/linux-libc-headers.inc                                                             |  7 ++++++-
 meta/recipes-kernel/linux-libc-headers/linux-libc-headers/0001-Allow-overriding-host-compiler-name-from-environment.patch | 32 ++++++++++++++++++++++++++++++++
 meta/recipes-kernel/linux/linux-yocto.inc                                                                                 |  4 ++++
 meta/recipes-kernel/linux/linux-yocto/0001-Allow-overriding-host-compiler-name-from-environment.patch                     | 32 ++++++++++++++++++++++++++++++++
 12 files changed, 153 insertions(+), 13 deletions(-)
 create mode 100644 meta/recipes-core/busybox/busybox/0001-Allow-overriding-of-host-compiler-names.patch
 create mode 100644 meta/recipes-core/glibc/glibc/0001-locale-fix-hard-coded-reference-to-gcc-E.patch
 create mode 100644 meta/recipes-kernel/linux-libc-headers/linux-libc-headers/0001-Allow-overriding-host-compiler-name-from-environment.patch
 create mode 100644 meta/recipes-kernel/linux/linux-yocto/0001-Allow-overriding-host-compiler-name-from-environment.patch

-- 
git-series 0.8.9

[PATCH 1/8] [autotools] export CCLD_FOR_BUILD

[Jérémy Rosen]

The autotools class already export most *_FOR_BUILD from bitbake's
BUILD_* variables. Somehow the variable CCLD_FOR_BUILD was missing

At least libpcre uses that variable and will use gcc instead of BUILD_CCLD
to link binaries

Signed-off-by: Jérémy Rosen <jeremy.rosen@smile.fr>
---
 meta/classes/autotools.bbclass | 2 ++
 1 file changed, 2 insertions(+), 0 deletions(-)

diff --git a/meta/classes/autotools.bbclass b/meta/classes/autotools.bbclass
index 076899c..9041021 100644
--- a/meta/classes/autotools.bbclass
+++ b/meta/classes/autotools.bbclass
@@ -49,6 +49,8 @@ export CXXFLAGS_FOR_BUILD="${BUILD_CXXFLAGS}"
 export LD_FOR_BUILD = "${BUILD_LD}"
 export LDFLAGS_FOR_BUILD = "${BUILD_LDFLAGS}"
 
+export CCLD_FOR_BUILD = "${BUILD_CCLD}"
+
 def append_libtool_sysroot(d):
     # Only supply libtool sysroot option for non-native packages
     if not bb.data.inherits_class('native', d):
-- 
git-series 0.8.9

Re: [PATCH 1/8] [autotools] export CCLD_FOR_BUILD

[Khem Raj]

[-- Attachment #1: Type: text/plain, Size: 1507 bytes --]


> On Aug 23, 2016, at 12:25 AM, Jérémy Rosen <jeremy.rosen@smile.fr> wrote:
> 
> The autotools class already export most *_FOR_BUILD from bitbake's
> BUILD_* variables. Somehow the variable CCLD_FOR_BUILD was missing
> 
> At least libpcre uses that variable and will use gcc instead of BUILD_CCLD
> to link binaries
> 
> Signed-off-by: Jérémy Rosen <jeremy.rosen@smile.fr>
> ---
> meta/classes/autotools.bbclass | 2 ++
> 1 file changed, 2 insertions(+), 0 deletions(-)
> 
> diff --git a/meta/classes/autotools.bbclass b/meta/classes/autotools.bbclass
> index 076899c..9041021 100644
> --- a/meta/classes/autotools.bbclass
> +++ b/meta/classes/autotools.bbclass
> @@ -49,6 +49,8 @@ export CXXFLAGS_FOR_BUILD="${BUILD_CXXFLAGS}"
> export LD_FOR_BUILD = "${BUILD_LD}"
> export LDFLAGS_FOR_BUILD = "${BUILD_LDFLAGS}"
> 
> +export CCLD_FOR_BUILD = "${BUILD_CCLD}”

if its used by just one recipe then its not worth abstracting it out. Perhaps
fixing
https://github.com/openembedded/openembedded-core/blob/master/meta/recipes-support/libpcre/libpcre/pcre-cross.patch
is another option ?

> +
> def append_libtool_sysroot(d):
>     # Only supply libtool sysroot option for non-native packages
>     if not bb.data.inherits_class('native', d):
> --
> git-series 0.8.9
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core


[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 211 bytes --]

Re: [PATCH 1/8] [autotools] export CCLD_FOR_BUILD

[Jérémy Rosen]

On 24/08/2016 02:50, Khem Raj wrote:
>> On Aug 23, 2016, at 12:25 AM, Jérémy Rosen <jeremy.rosen@smile.fr> wrote:
>>
>> The autotools class already export most *_FOR_BUILD from bitbake's
>> BUILD_* variables. Somehow the variable CCLD_FOR_BUILD was missing
>>
>> At least libpcre uses that variable and will use gcc instead of BUILD_CCLD
>> to link binaries
>>
>> Signed-off-by: Jérémy Rosen <jeremy.rosen@smile.fr>
>> ---
>> meta/classes/autotools.bbclass | 2 ++
>> 1 file changed, 2 insertions(+), 0 deletions(-)
>>
>> diff --git a/meta/classes/autotools.bbclass b/meta/classes/autotools.bbclass
>> index 076899c..9041021 100644
>> --- a/meta/classes/autotools.bbclass
>> +++ b/meta/classes/autotools.bbclass
>> @@ -49,6 +49,8 @@ export CXXFLAGS_FOR_BUILD="${BUILD_CXXFLAGS}"
>> export LD_FOR_BUILD = "${BUILD_LD}"
>> export LDFLAGS_FOR_BUILD = "${BUILD_LDFLAGS}"
>>
>> +export CCLD_FOR_BUILD = "${BUILD_CCLD}”
> if its used by just one recipe then its not worth abstracting it out. Perhaps
> fixing
> https://github.com/openembedded/openembedded-core/blob/master/meta/recipes-support/libpcre/libpcre/pcre-cross.patch
> is another option ?
I'll have a look, I have been looking around and i'm not even sure if 
CC_FOR_BUILD is an autoconf thing... CCLD seems to be unique to that 
recipe. i'll look at the patch

>> +
>> def append_libtool_sysroot(d):
>>      # Only supply libtool sysroot option for non-native packages
>>      if not bb.data.inherits_class('native', d):
>> --
>> git-series 0.8.9
>> --
>> _______________________________________________
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [PATCH 1/8] [autotools] export CCLD_FOR_BUILD

[Jérémy Rosen]

(Adding original patch author to mail)


On 24/08/2016 13:05, Jérémy Rosen wrote:

[...]
>>>
>>> +export CCLD_FOR_BUILD = "${BUILD_CCLD}”
>> if its used by just one recipe then its not worth abstracting it out. 
>> Perhaps
>> fixing
>> https://github.com/openembedded/openembedded-core/blob/master/meta/recipes-support/libpcre/libpcre/pcre-cross.patch 
>>
>> is another option ?
> I'll have a look, I have been looking around and i'm not even sure if 
> CC_FOR_BUILD is an autoconf thing... CCLD seems to be unique to that 
> recipe. i'll look at the patch
>
ok, so CC_FOR_BUILD seems to be a common convention and CCLD_FOR_BUILD 
seems only used by our patch for pcre. Fixing it to use CC_FOR_BUILD for 
linking is trivial

but the patch is marked as submitted upstream, so Fahad... what is the 
status ? how can we do that ?

I can also set CCLD_FOR_BUILD in ther .bb file instead of 
autotools.bbclass, that's trivial... the question is whether we should 
fix the patch or not...

>>> +
>>> def append_libtool_sysroot(d):
>>>      # Only supply libtool sysroot option for non-native packages
>>>      if not bb.data.inherits_class('native', d):
>>> -- 
>>> git-series 0.8.9
>>> -- 
>>> _______________________________________________
>>> Openembedded-core mailing list
>>> Openembedded-core@lists.openembedded.org
>>> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>

Re: [PATCH 1/8] [autotools] export CCLD_FOR_BUILD

[Burton, Ross]

[-- Attachment #1: Type: text/plain, Size: 855 bytes --]

On 24 August 2016 at 12:28, Jérémy Rosen <jeremy.rosen@smile.fr> wrote:

> ok, so CC_FOR_BUILD seems to be a common convention and CCLD_FOR_BUILD
> seems only used by our patch for pcre. Fixing it to use CC_FOR_BUILD for
> linking is trivial
>
> but the patch is marked as submitted upstream, so Fahad... what is the
> status ? how can we do that ?
>
> I can also set CCLD_FOR_BUILD in ther .bb file instead of
> autotools.bbclass, that's trivial... the question is whether we should fix
> the patch or not...
>

CC_FOR_BUILD and CPP_FOR_BUILD are de facto standards by virtue of being
part of autoconf-archive:
https://www.gnu.org/software/autoconf-archive/ax_prog_cc_for_build.html

Looking at the patch wouldn't it be possible to avoid the entire .c -> .o
-> binary process and just go from .c -> binary via CC_FOR_BUILD?

Ross

[-- Attachment #2: Type: text/html, Size: 1427 bytes --]

Re: [PATCH 1/8] [autotools] export CCLD_FOR_BUILD

[Jérémy Rosen]

[-- Attachment #1: Type: text/plain, Size: 1331 bytes --]



On 24/08/2016 21:56, Burton, Ross wrote:
>
> On 24 August 2016 at 12:28, Jérémy Rosen <jeremy.rosen@smile.fr 
> <mailto:jeremy.rosen@smile.fr>> wrote:
>
>     ok, so CC_FOR_BUILD seems to be a common convention and
>     CCLD_FOR_BUILD seems only used by our patch for pcre. Fixing it to
>     use CC_FOR_BUILD for linking is trivial
>
>     but the patch is marked as submitted upstream, so Fahad... what is
>     the status ? how can we do that ?
>
>     I can also set CCLD_FOR_BUILD in ther .bb file instead of
>     autotools.bbclass, that's trivial... the question is whether we
>     should fix the patch or not...
>
>
> CC_FOR_BUILD and CPP_FOR_BUILD are de facto standards by virtue of 
> being part of autoconf-archive: 
> https://www.gnu.org/software/autoconf-archive/ax_prog_cc_for_build.html
>
> Looking at the patch wouldn't it be possible to avoid the entire .c -> 
> .o -> binary process and just go from .c -> binary via CC_FOR_BUILD?
Probably, but again the patch has been pushed upstream by someone else 
and I need to contact that person first to see how to handle it.

I can avoid that by defining CCLD_FOR_BUILD in the recipe, but since I 
need to wait for glibc for v2 anyway, I'm not in a rush...

if I have no news, I'll do that for V2


Regards
Jeremy
>
> Ross


[-- Attachment #2: Type: text/html, Size: 2983 bytes --]

Re: [PATCH 1/8] [autotools] export CCLD_FOR_BUILD

[Burton, Ross]

[-- Attachment #1: Type: text/plain, Size: 301 bytes --]

On 25 August 2016 at 13:40, Jérémy Rosen <jeremy.rosen@smile.fr> wrote:

> I can avoid that by defining CCLD_FOR_BUILD in the recipe, but since I
> need to wait for glibc for v2 anyway, I'm not in a rush...
>
> if I have no news, I'll do that for V2
>

Cool, looking forward to v2.

Ross

[-- Attachment #2: Type: text/html, Size: 719 bytes --]

[PATCH 2/8] [cross] export CC family from BUILD_* for cross compilers

[Jérémy Rosen]

cross-compilers are native recipes that need to be compiled by the host's
compiler. However then do not use native.bbclass

As a consequence, the various CC, CXX etc environment variables are not
correctly set and they will not honor the host compiler name provided
by the BUILD_* variables.

Signed-off-by: Jérémy Rosen <jeremy.rosen@smile.fr>
---
 meta/classes/cross.bbclass | 12 ++++++++++++
 1 file changed, 12 insertions(+), 0 deletions(-)

diff --git a/meta/classes/cross.bbclass b/meta/classes/cross.bbclass
index 81d1c9d..8d1e779 100644
--- a/meta/classes/cross.bbclass
+++ b/meta/classes/cross.bbclass
@@ -68,4 +68,16 @@ do_install () {
 
 USE_NLS = "no"
 
+export CC = "${BUILD_CC}"
+export CXX = "${BUILD_CXX}"
+export FC = "${BUILD_FC}"
+export CPP = "${BUILD_CPP}"
+export LD = "${BUILD_LD}"
+export CCLD = "${BUILD_CCLD}"
+export AR = "${BUILD_AR}"
+export AS = "${BUILD_AS}"
+export RANLIB = "${BUILD_RANLIB}"
+export STRIP = "${BUILD_STRIP}"
+export NM = "${BUILD_NM}"
+
 inherit nopackages
-- 
git-series 0.8.9

Re: [PATCH 2/8] [cross] export CC family from BUILD_* for cross compilers

[Peter Kjellerstedt]

> -----Original Message-----
> From: openembedded-core-bounces@lists.openembedded.org
> [mailto:openembedded-core-bounces@lists.openembedded.org] On Behalf Of
> Jérémy Rosen
> Sent: den 23 augusti 2016 09:25
> To: openembedded-core@lists.openembedded.org
> Subject: [OE-core] [PATCH 2/8] [cross] export CC family from BUILD_*
> for cross compilers
> 
> cross-compilers are native recipes that need to be compiled by the host's
> compiler. However then do not use native.bbclass

Change "then" to "they".

//Peter

Re: [PATCH 2/8] [cross] export CC family from BUILD_* for cross compilers

[Burton, Ross]

[-- Attachment #1: Type: text/plain, Size: 1597 bytes --]

FYI, git am strips anything inside [square brackets] when applying, so your
[cross] etc doesn't make it into the series.  If you submit a v2 please
change [cross] to cross:.

Ross

On 23 August 2016 at 08:25, Jérémy Rosen <jeremy.rosen@smile.fr> wrote:

> cross-compilers are native recipes that need to be compiled by the host's
> compiler. However then do not use native.bbclass
>
> As a consequence, the various CC, CXX etc environment variables are not
> correctly set and they will not honor the host compiler name provided
> by the BUILD_* variables.
>
> Signed-off-by: Jérémy Rosen <jeremy.rosen@smile.fr>
> ---
>  meta/classes/cross.bbclass | 12 ++++++++++++
>  1 file changed, 12 insertions(+), 0 deletions(-)
>
> diff --git a/meta/classes/cross.bbclass b/meta/classes/cross.bbclass
> index 81d1c9d..8d1e779 100644
> --- a/meta/classes/cross.bbclass
> +++ b/meta/classes/cross.bbclass
> @@ -68,4 +68,16 @@ do_install () {
>
>  USE_NLS = "no"
>
> +export CC = "${BUILD_CC}"
> +export CXX = "${BUILD_CXX}"
> +export FC = "${BUILD_FC}"
> +export CPP = "${BUILD_CPP}"
> +export LD = "${BUILD_LD}"
> +export CCLD = "${BUILD_CCLD}"
> +export AR = "${BUILD_AR}"
> +export AS = "${BUILD_AS}"
> +export RANLIB = "${BUILD_RANLIB}"
> +export STRIP = "${BUILD_STRIP}"
> +export NM = "${BUILD_NM}"
> +
>  inherit nopackages
> --
> git-series 0.8.9
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>

[-- Attachment #2: Type: text/html, Size: 2424 bytes --]

Re: [PATCH 2/8] [cross] export CC family from BUILD_* for cross compilers

[Jérémy Rosen]

[-- Attachment #1: Type: text/plain, Size: 2055 bytes --]



On 23/08/2016 16:46, Burton, Ross wrote:
> FYI, git am strips anything inside [square brackets] when applying, so 
> your [cross] etc doesn't make it into the series.  If you submit a v2 
> please change [cross] to cross:.
>
I didn't know that... will fix

> Ross
>
> On 23 August 2016 at 08:25, Jérémy Rosen <jeremy.rosen@smile.fr 
> <mailto:jeremy.rosen@smile.fr>> wrote:
>
>     cross-compilers are native recipes that need to be compiled by the
>     host's
>     compiler. However then do not use native.bbclass
>
>     As a consequence, the various CC, CXX etc environment variables
>     are not
>     correctly set and they will not honor the host compiler name provided
>     by the BUILD_* variables.
>
>     Signed-off-by: Jérémy Rosen <jeremy.rosen@smile.fr
>     <mailto:jeremy.rosen@smile.fr>>
>     ---
>      meta/classes/cross.bbclass | 12 ++++++++++++
>      1 file changed, 12 insertions(+), 0 deletions(-)
>
>     diff --git a/meta/classes/cross.bbclass b/meta/classes/cross.bbclass
>     index 81d1c9d..8d1e779 100644
>     --- a/meta/classes/cross.bbclass
>     +++ b/meta/classes/cross.bbclass
>     @@ -68,4 +68,16 @@ do_install () {
>
>      USE_NLS = "no"
>
>     +export CC = "${BUILD_CC}"
>     +export CXX = "${BUILD_CXX}"
>     +export FC = "${BUILD_FC}"
>     +export CPP = "${BUILD_CPP}"
>     +export LD = "${BUILD_LD}"
>     +export CCLD = "${BUILD_CCLD}"
>     +export AR = "${BUILD_AR}"
>     +export AS = "${BUILD_AS}"
>     +export RANLIB = "${BUILD_RANLIB}"
>     +export STRIP = "${BUILD_STRIP}"
>     +export NM = "${BUILD_NM}"
>     +
>      inherit nopackages
>     --
>     git-series 0.8.9
>     --
>     _______________________________________________
>     Openembedded-core mailing list
>     Openembedded-core@lists.openembedded.org
>     <mailto:Openembedded-core@lists.openembedded.org>
>     http://lists.openembedded.org/mailman/listinfo/openembedded-core
>     <http://lists.openembedded.org/mailman/listinfo/openembedded-core>
>
>


[-- Attachment #2: Type: text/html, Size: 3860 bytes --]

[PATCH 3/8] [rpm] force a configure before make distclean

[Jérémy Rosen]

The rpm recipe forces a distclean in the syck subdirectory. That call
uses the result of the last ./configure call (that was made by the rpm
developers) which assumes that gcc exists and is in the path

running ./configure before that ensures that BUILD_CC is properly used and
that the make distclean succeeds

Signed-off-by: Jérémy Rosen <jeremy.rosen@smile.fr>
---
 meta/recipes-devtools/rpm/rpm_5.4.16.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-devtools/rpm/rpm_5.4.16.bb b/meta/recipes-devtools/rpm/rpm_5.4.16.bb
index 84adef6..6b82c6d 100644
--- a/meta/recipes-devtools/rpm/rpm_5.4.16.bb
+++ b/meta/recipes-devtools/rpm/rpm_5.4.16.bb
@@ -526,7 +526,7 @@ do_configure() {
 	sed -e 's/pkg-config --exists uuid/pkg-config --exists ossp-uuid/g' \
 	    -e 's/pkg-config uuid/pkg-config ossp-uuid/g' -i ${S}/configure
 
-	( cd ${S}/syck ; set +e ; rm -- -l* ; make distclean ) || :
+	( cd ${S}/syck ; set +e ; rm -- -l* ; ./configure ; make distclean ) || :
 
 	export varprefix=${localstatedir}
 	oe_runconf
-- 
git-series 0.8.9

Re: [PATCH 3/8] [rpm] force a configure before make distclean

[Burton, Ross]

[-- Attachment #1: Type: text/plain, Size: 521 bytes --]

On 23 August 2016 at 08:25, Jérémy Rosen <jeremy.rosen@smile.fr> wrote:

> -       ( cd ${S}/syck ; set +e ; rm -- -l* ; make distclean ) || :
> +       ( cd ${S}/syck ; set +e ; rm -- -l* ; ./configure ; make distclean
> ) || :
>

Running configure without all the options it needs to actually work just so
that distclean works in a subbuild that shouldn't be breaking on rebuilds
because we have out of tree builds scares me a little.

Mark, you added this line, can you remember what it was for?

Ross

[-- Attachment #2: Type: text/html, Size: 1000 bytes --]

Re: [PATCH 3/8] [rpm] force a configure before make distclean

[Mark Hatle]

On 8/23/16 11:54 AM, Burton, Ross wrote:
> 
> On 23 August 2016 at 08:25, Jérémy Rosen <jeremy.rosen@smile.fr
> <mailto:jeremy.rosen@smile.fr>> wrote:
> 
>     -       ( cd ${S}/syck ; set +e ; rm -- -l* ; make distclean ) || :
>     +       ( cd ${S}/syck ; set +e ; rm -- -l* ; ./configure ; make distclean )
>     || :
> 
> 
> Running configure without all the options it needs to actually work just so that
> distclean works in a subbuild that shouldn't be breaking on rebuilds because we
> have out of tree builds scares me a little.
> 
> Mark, you added this line, can you remember what it was for?

The syck version can be preconfigured, and if it is -- it's wrong.

The 'set +e' is specifically in there to ALLOW it to fail.

If it is configured, we much remove the junk and clean it.. if it's not been
configured, we ignore the make distclean failure.

So I'm not sure why it is necessary to make the change.  'Failure is permitted',
and make distclean shouldn't be using any 'BUILD_CC' values from prior builds...
since it's only wiping everything that MAY have been previously built and leaked
into the release archive.

--Mark

> Ross

Re: [PATCH 3/8] [rpm] force a configure before make distclean

[Jérémy Rosen]

On 23/08/2016 19:16, Mark Hatle wrote:
> On 8/23/16 11:54 AM, Burton, Ross wrote:
>> On 23 August 2016 at 08:25, Jérémy Rosen <jeremy.rosen@smile.fr
>> <mailto:jeremy.rosen@smile.fr>> wrote:
>>
>>      -       ( cd ${S}/syck ; set +e ; rm -- -l* ; make distclean ) || :
>>      +       ( cd ${S}/syck ; set +e ; rm -- -l* ; ./configure ; make distclean )
>>      || :
>>
>>
>> Running configure without all the options it needs to actually work just so that
>> distclean works in a subbuild that shouldn't be breaking on rebuilds because we
>> have out of tree builds scares me a little.
>>
>> Mark, you added this line, can you remember what it was for?
> The syck version can be preconfigured, and if it is -- it's wrong.
>
> The 'set +e' is specifically in there to ALLOW it to fail.
>
> If it is configured, we much remove the junk and clean it.. if it's not been
> configured, we ignore the make distclean failure.
>
> So I'm not sure why it is necessary to make the change.  'Failure is permitted',
> and make distclean shouldn't be using any 'BUILD_CC' values from prior builds...
> since it's only wiping everything that MAY have been previously built and leaked
> into the release archive.
I havn't dived deeply on the whole chain of event, I have to admit that 
autotools scares me...

This particular line does work as expected. the set +e does indeed allow 
the make distclean to fail.

The problem is that if that distclean is not failing because nothing 
needs to be done it is failing because it can't find gcc. The junk isn't 
clean and the build of rpm will fail later complaining that the syck 
subdir is
already configured.

This is probably why you run the make distclean in the first place.

The need for gcc is weird... the error message I get is that no working 
version of gcc could be found, but the trace itself looks more like a 
call to configure (as if make distclean did some configuration check)

Again, I have not dug deeply enough in here to completely understand 
what's going on. I'd gladly take any clues you might have for a better fix.

>
> --Mark
>
>> Ross
>

Re: [PATCH 3/8] [rpm] force a configure before make distclean

[Mark Hatle]

On 8/24/16 2:44 AM, Jérémy Rosen wrote:
> 
> 
> On 23/08/2016 19:16, Mark Hatle wrote:
>> On 8/23/16 11:54 AM, Burton, Ross wrote:
>>> On 23 August 2016 at 08:25, Jérémy Rosen <jeremy.rosen@smile.fr
>>> <mailto:jeremy.rosen@smile.fr>> wrote:
>>>
>>>      -       ( cd ${S}/syck ; set +e ; rm -- -l* ; make distclean ) || :
>>>      +       ( cd ${S}/syck ; set +e ; rm -- -l* ; ./configure ; make distclean )
>>>      || :
>>>
>>>
>>> Running configure without all the options it needs to actually work just so that
>>> distclean works in a subbuild that shouldn't be breaking on rebuilds because we
>>> have out of tree builds scares me a little.
>>>
>>> Mark, you added this line, can you remember what it was for?
>> The syck version can be preconfigured, and if it is -- it's wrong.
>>
>> The 'set +e' is specifically in there to ALLOW it to fail.
>>
>> If it is configured, we much remove the junk and clean it.. if it's not been
>> configured, we ignore the make distclean failure.
>>
>> So I'm not sure why it is necessary to make the change.  'Failure is permitted',
>> and make distclean shouldn't be using any 'BUILD_CC' values from prior builds...
>> since it's only wiping everything that MAY have been previously built and leaked
>> into the release archive.
> I havn't dived deeply on the whole chain of event, I have to admit that 
> autotools scares me...
> 
> This particular line does work as expected. the set +e does indeed allow 
> the make distclean to fail.
> 
> The problem is that if that distclean is not failing because nothing 
> needs to be done it is failing because it can't find gcc. The junk isn't 
> clean and the build of rpm will fail later complaining that the syck 
> subdir is
> already configured.
> 
> This is probably why you run the make distclean in the first place.
> 
> The need for gcc is weird... the error message I get is that no working 
> version of gcc could be found, but the trace itself looks more like a 
> call to configure (as if make distclean did some configuration check)
> 
> Again, I have not dug deeply enough in here to completely understand 
> what's going on. I'd gladly take any clues you might have for a better fix.

Make often has a rule looking at the time stamp of specific files and re-running
specific autotools if they are 'out of date'.  That COULD be the cause of the
errant call to gcc?

I have not observed the above occurring -- but the key thing is that syck needs
to be cleaned of the generated files.  We don't want to run any host commands
other then clean it.

If you have to replace it with something else, you will need to identify all of
the files that need to be cleaned and manually remove them avoiding the
distclean call.

Easiest way to do that.... extract the source for syck, back it up, run the make
distclean.. compare the difference and use that list as a replacement 'cleanup'
command.

--Mark

>>
>> --Mark
>>
>>> Ross
>>
> 

Re: [PATCH 3/8] [rpm] force a configure before make distclean

[Jérémy Rosen]

On 24/08/2016 16:13, Mark Hatle wrote:
>
> Make often has a rule looking at the time stamp of specific files and re-running
> specific autotools if they are 'out of date'.  That COULD be the cause of the
> errant call to gcc?
that would make sense...
>
> I have not observed the above occurring -- but the key thing is that syck needs
> to be cleaned of the generated files.  We don't want to run any host commands
> other then clean it.
>
> If you have to replace it with something else, you will need to identify all of
> the files that need to be cleaned and manually remove them avoiding the
> distclean call.
>
> Easiest way to do that.... extract the source for syck, back it up, run the make
> distclean.. compare the difference and use that list as a replacement 'cleanup'
> command.

That wouldn't be very robust to future change in syck, i'm afraid... but 
i'll have a look.
>
> --Mark
>
>

Re: [PATCH 3/8] [rpm] force a configure before make distclean

[Mark Hatle]

On 8/24/16 9:17 AM, Jérémy Rosen wrote:
> 
> 
> On 24/08/2016 16:13, Mark Hatle wrote:
>>
>> Make often has a rule looking at the time stamp of specific files and re-running
>> specific autotools if they are 'out of date'.  That COULD be the cause of the
>> errant call to gcc?
> that would make sense...
>>
>> I have not observed the above occurring -- but the key thing is that syck needs
>> to be cleaned of the generated files.  We don't want to run any host commands
>> other then clean it.
>>
>> If you have to replace it with something else, you will need to identify all of
>> the files that need to be cleaned and manually remove them avoiding the
>> distclean call.
>>
>> Easiest way to do that.... extract the source for syck, back it up, run the make
>> distclean.. compare the difference and use that list as a replacement 'cleanup'
>> command.
> 
> That wouldn't be very robust to future change in syck, i'm afraid... but 
> i'll have a look.

There is nothing robust about this change for future work.  Future versions will
have to do the work in a different way -- and hopefully won't have pre-built
crap slipped into the download that we have to cleanup.

So I have no concern about future proofing this, as I know the next integration
-will- be different in this case.

--Mark

>>
>> --Mark
>>
>>
> 

[PATCH 4/8] [linux-yocto] allow overriding compiler name in KConfig

[Jérémy Rosen]

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
---
 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"
+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@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

Re: [PATCH 4/8] [linux-yocto] allow overriding compiler name in KConfig

[Bruce Ashfield]

[-- Attachment #1: Type: text/plain, Size: 3682 bytes --]

On Tue, Aug 23, 2016 at 3:25 AM, Jérémy Rosen <jeremy.rosen@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.

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@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@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>



-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await thee
at its end"

[-- Attachment #2: Type: text/html, Size: 5230 bytes --]

Re: [PATCH 4/8] [linux-yocto] allow overriding compiler name in KConfig

[Bruce Ashfield]

[-- Attachment #1: Type: text/plain, Size: 4512 bytes --]

On Tue, Aug 23, 2016 at 9:36 AM, Bruce Ashfield <bruce.ashfield@gmail.com>
wrote:

> On Tue, Aug 23, 2016 at 3:25 AM, Jérémy Rosen <jeremy.rosen@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.

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/linu
>> x-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-h
>> ost-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-overridin
>> g-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-overridin
>> g-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@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@lists.openembedded.org
>> 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"

[-- Attachment #2: Type: text/html, Size: 6835 bytes --]

Re: [PATCH 4/8] [linux-yocto] allow overriding compiler name in KConfig

[Jérémy Rosen]

[-- Attachment #1: Type: text/plain, Size: 6360 bytes --]



On 23/08/2016 15:41, Bruce Ashfield wrote:
>
>
> On Tue, Aug 23, 2016 at 9:36 AM, Bruce Ashfield 
> <bruce.ashfield@gmail.com <mailto:bruce.ashfield@gmail.com>> wrote:
>
>     On Tue, Aug 23, 2016 at 3:25 AM, Jérémy Rosen
>     <jeremy.rosen@smile.fr <mailto:jeremy.rosen@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@smile.fr <mailto:jeremy.rosen@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@lists.openembedded.org
>         <mailto:Openembedded-core@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"


[-- Attachment #2: Type: text/html, Size: 14023 bytes --]

Re: [PATCH 4/8] [linux-yocto] allow overriding compiler name in KConfig

[Jérémy Rosen]

[-- Attachment #1: Type: text/plain, Size: 4864 bytes --]



On 23/08/2016 15:36, Bruce Ashfield wrote:
> On Tue, Aug 23, 2016 at 3:25 AM, Jérémy Rosen <jeremy.rosen@smile.fr 
> <mailto:jeremy.rosen@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.
>
> If there's an issue, we need to fix it upstream .. not here.
Ok, two answers here

* the problem is specifically when the kernel builds a binary for the 
host. not when the kernel itself is compiled. i.e it is the binary 
needed to run menuconfig itself that was the problem.
* I have contacted the KConfig maintainer and he has offered me a more 
elegant solution to that problem that does not require an upstream 
patch. I will propose a better fix for the
three instances of KConfig (kernel, kernel headers, busybox) in V2 of 
this patch

Sorry for the churn, I am compiling his approch as we speak :)
>
>     ---
>      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@smile.fr
>     <mailto:jeremy.rosen@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@lists.openembedded.org
>     <mailto:Openembedded-core@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"


[-- Attachment #2: Type: text/html, Size: 9018 bytes --]

[PATCH 5/8] [linux-libc-headers] allow overriding compiler name in KConfig

[Jérémy Rosen]

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
---
 meta/recipes-kernel/linux-libc-headers/linux-libc-headers.inc                                                             |  7 ++++++-
 meta/recipes-kernel/linux-libc-headers/linux-libc-headers/0001-Allow-overriding-host-compiler-name-from-environment.patch | 32 ++++++++++++++++++++++++++++++++
 2 files changed, 38 insertions(+), 1 deletion(-)
 create mode 100644 meta/recipes-kernel/linux-libc-headers/linux-libc-headers/0001-Allow-overriding-host-compiler-name-from-environment.patch

diff --git a/meta/recipes-kernel/linux-libc-headers/linux-libc-headers.inc b/meta/recipes-kernel/linux-libc-headers/linux-libc-headers.inc
index 92acf8a..18bd080 100644
--- a/meta/recipes-kernel/linux-libc-headers/linux-libc-headers.inc
+++ b/meta/recipes-kernel/linux-libc-headers/linux-libc-headers.inc
@@ -46,7 +46,9 @@ inherit kernel-arch
 
 KORG_ARCHIVE_COMPRESSION ?= "xz"
 
-SRC_URI = "${KERNELORG_MIRROR}/linux/kernel/v${HEADER_FETCH_VER}/linux-${PV}.tar.${KORG_ARCHIVE_COMPRESSION}"
+SRC_URI = "${KERNELORG_MIRROR}/linux/kernel/v${HEADER_FETCH_VER}/linux-${PV}.tar.${KORG_ARCHIVE_COMPRESSION} \
+           file://0001-Allow-overriding-host-compiler-name-from-environment.patch \
+           "
 
 S = "${WORKDIR}/linux-${PV}"
 
@@ -77,3 +79,6 @@ RRECOMMENDS_${PN}-dbg = "${PN}-dev (= ${EXTENDPKGV})"
 
 INHIBIT_DEFAULT_DEPS = "1"
 DEPENDS += "unifdef-native"
+
+export HOSTCC="${BUILD_CC}"
+export HOSTCXX="${BUILD_CXX}"
diff --git a/meta/recipes-kernel/linux-libc-headers/linux-libc-headers/0001-Allow-overriding-host-compiler-name-from-environment.patch b/meta/recipes-kernel/linux-libc-headers/linux-libc-headers/0001-Allow-overriding-host-compiler-name-from-environment.patch
new file mode 100644
index 0000000..6fcfbc8
--- /dev/null
+++ b/meta/recipes-kernel/linux-libc-headers/linux-libc-headers/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@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

Re: [PATCH 5/8] [linux-libc-headers] allow overriding compiler name in KConfig

[Bruce Ashfield]

[-- Attachment #1: Type: text/plain, Size: 4254 bytes --]

On Tue, Aug 23, 2016 at 3:25 AM, Jérémy Rosen <jeremy.rosen@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
> ---
>  meta/recipes-kernel/linux-libc-headers/linux-libc-headers.inc
>                                                  |  7 ++++++-
>  meta/recipes-kernel/linux-libc-headers/linux-libc-
> headers/0001-Allow-overriding-host-compiler-name-from-environment.patch |
> 32 ++++++++++++++++++++++++++++++++
>  2 files changed, 38 insertions(+), 1 deletion(-)
>  create mode 100644 meta/recipes-kernel/linux-libc-headers/linux-libc-
> headers/0001-Allow-overriding-host-compiler-name-from-environment.patch
>
> diff --git a/meta/recipes-kernel/linux-libc-headers/linux-libc-headers.inc
> b/meta/recipes-kernel/linux-libc-headers/linux-libc-headers.inc
> index 92acf8a..18bd080 100644
> --- a/meta/recipes-kernel/linux-libc-headers/linux-libc-headers.inc
> +++ b/meta/recipes-kernel/linux-libc-headers/linux-libc-headers.inc
> @@ -46,7 +46,9 @@ inherit kernel-arch
>
>  KORG_ARCHIVE_COMPRESSION ?= "xz"
>
> -SRC_URI = "${KERNELORG_MIRROR}/linux/kernel/v${HEADER_FETCH_VER}/
> linux-${PV}.tar.${KORG_ARCHIVE_COMPRESSION}"
> +SRC_URI = "${KERNELORG_MIRROR}/linux/kernel/v${HEADER_FETCH_VER}/
> linux-${PV}.tar.${KORG_ARCHIVE_COMPRESSION} \
> +           file://0001-Allow-overriding-host-compiler-name-from-environment.patch
> \
> +           "
>
>
We shouldn't be patching linux-libc-headers, and much less with a build
patch like this. libc-headers
are the c libraries interface to the kernel. If something is building
against the kernel itself, it needs
to go against the kernel source.

If this is broken, it needs to be fixed upstream.

But like the kernel patch, I can't tell exactly what problem you are trying
to fix. Can you be more
specific ?

Bruce


>  S = "${WORKDIR}/linux-${PV}"
>
> @@ -77,3 +79,6 @@ RRECOMMENDS_${PN}-dbg = "${PN}-dev (= ${EXTENDPKGV})"
>
>  INHIBIT_DEFAULT_DEPS = "1"
>  DEPENDS += "unifdef-native"
> +
> +export HOSTCC="${BUILD_CC}"
> +export HOSTCXX="${BUILD_CXX}"
> diff --git a/meta/recipes-kernel/linux-libc-headers/linux-libc-
> headers/0001-Allow-overriding-host-compiler-name-from-environment.patch
> b/meta/recipes-kernel/linux-libc-headers/linux-libc-
> headers/0001-Allow-overriding-host-compiler-name-from-environment.patch
> new file mode 100644
> index 0000000..6fcfbc8
> --- /dev/null
> +++ b/meta/recipes-kernel/linux-libc-headers/linux-libc-
> headers/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@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@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>



-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await thee
at its end"

[-- Attachment #2: Type: text/html, Size: 5914 bytes --]

Re: [PATCH 5/8] [linux-libc-headers] allow overriding compiler name in KConfig

[Khem Raj]

[-- Attachment #1.1: Type: text/plain, Size: 4844 bytes --]


> On Aug 23, 2016, at 6:39 AM, Bruce Ashfield <bruce.ashfield@gmail.com> wrote:
> 
> 
> 
> On Tue, Aug 23, 2016 at 3:25 AM, Jérémy Rosen <jeremy.rosen@smile.fr <mailto:jeremy.rosen@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
> ---
>  meta/recipes-kernel/linux-libc-headers/linux-libc-headers.inc                                                             |  7 ++++++-
>  meta/recipes-kernel/linux-libc-headers/linux-libc-headers/0001-Allow-overriding-host-compiler-name-from-environment.patch | 32 ++++++++++++++++++++++++++++++++
>  2 files changed, 38 insertions(+), 1 deletion(-)
>  create mode 100644 meta/recipes-kernel/linux-libc-headers/linux-libc-headers/0001-Allow-overriding-host-compiler-name-from-environment.patch
> 
> diff --git a/meta/recipes-kernel/linux-libc-headers/linux-libc-headers.inc b/meta/recipes-kernel/linux-libc-headers/linux-libc-headers.inc
> index 92acf8a..18bd080 100644
> --- a/meta/recipes-kernel/linux-libc-headers/linux-libc-headers.inc
> +++ b/meta/recipes-kernel/linux-libc-headers/linux-libc-headers.inc
> @@ -46,7 +46,9 @@ inherit kernel-arch
> 
>  KORG_ARCHIVE_COMPRESSION ?= "xz"
> 
> -SRC_URI = "${KERNELORG_MIRROR}/linux/kernel/v${HEADER_FETCH_VER}/linux-${PV}.tar.${KORG_ARCHIVE_COMPRESSION}"
> +SRC_URI = "${KERNELORG_MIRROR}/linux/kernel/v${HEADER_FETCH_VER}/linux-${PV}.tar.${KORG_ARCHIVE_COMPRESSION} \
> +           file://0001-Allow-overriding-host-compiler-name-from-environment.patch \
> +           "
> 
> 
> We shouldn't be patching linux-libc-headers, and much less with a build patch like this. libc-headers
> are the c libraries interface to the kernel. If something is building against the kernel itself, it needs
> to go against the kernel source.
> 
> If this is broken, it needs to be fixed upstream.

I agree. now a days we have more than gcc available as system C compiler perhaps your patch might be upstream worthy.

> 
> But like the kernel patch, I can't tell exactly what problem you are trying to fix. Can you be more
> specific ?
> 
> Bruce
> 
>  S = "${WORKDIR}/linux-${PV}"
> 
> @@ -77,3 +79,6 @@ RRECOMMENDS_${PN}-dbg = "${PN}-dev (= ${EXTENDPKGV})"
> 
>  INHIBIT_DEFAULT_DEPS = "1"
>  DEPENDS += "unifdef-native"
> +
> +export HOSTCC="${BUILD_CC}"
> +export HOSTCXX="${BUILD_CXX}"
> diff --git a/meta/recipes-kernel/linux-libc-headers/linux-libc-headers/0001-Allow-overriding-host-compiler-name-from-environment.patch b/meta/recipes-kernel/linux-libc-headers/linux-libc-headers/0001-Allow-overriding-host-compiler-name-from-environment.patch
> new file mode 100644
> index 0000000..6fcfbc8
> --- /dev/null
> +++ b/meta/recipes-kernel/linux-libc-headers/linux-libc-headers/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@smile.fr <mailto:jeremy.rosen@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@lists.openembedded.org <mailto:Openembedded-core@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"
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core


[-- Attachment #1.2: Type: text/html, Size: 8891 bytes --]

[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 211 bytes --]

Re: [PATCH 5/8] [linux-libc-headers] allow overriding compiler name in KConfig

[Jérémy Rosen]

[-- Attachment #1: Type: text/plain, Size: 776 bytes --]

[...]
>>
>> If this is broken, it needs to be fixed upstream.
>
> I agree. now a days we have more than gcc available as system C 
> compiler perhaps your patch might be upstream worthy.
>
As stated elsewhere, I now have a proper way to override the variables 
without patching the build system. V2 of this patch serie will get rid 
of that patch entirely and deal with it purely in the recipe
>> -- 
>> "Thou shalt not follow the NULL pointer, for chaos and madness await 
>> thee at its end"
>> -- 
>> _______________________________________________
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org 
>> <mailto:Openembedded-core@lists.openembedded.org>
>> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>


[-- Attachment #2: Type: text/html, Size: 2518 bytes --]

[PATCH 6/8] [busybox] allow overriding compiler name in KConfig

[Jérémy Rosen]

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
---
 meta/recipes-core/busybox/busybox.inc                                                |  5 +++++
 meta/recipes-core/busybox/busybox/0001-Allow-overriding-of-host-compiler-names.patch | 27 +++++++++++++++++++++++++++
 2 files changed, 32 insertions(+), 0 deletions(-)
 create mode 100644 meta/recipes-core/busybox/busybox/0001-Allow-overriding-of-host-compiler-names.patch

diff --git a/meta/recipes-core/busybox/busybox.inc b/meta/recipes-core/busybox/busybox.inc
index 39c2eef..defeb2e 100644
--- a/meta/recipes-core/busybox/busybox.inc
+++ b/meta/recipes-core/busybox/busybox.inc
@@ -47,6 +47,11 @@ CONFFILES_${PN}-mdev = "${sysconfdir}/mdev.conf"
 
 RRECOMMENDS_${PN} = "${PN}-syslog ${PN}-udhcpc"
 
+export HOSTCC = "${BUILD_CC}"
+export HOSTCXX = "${BUILD_CXX}"
+SRC_URI_append = " \
+           file://0001-Allow-overriding-of-host-compiler-names.patch \
+"
 inherit cml1 systemd update-rc.d ptest
 
 # internal helper
diff --git a/meta/recipes-core/busybox/busybox/0001-Allow-overriding-of-host-compiler-names.patch b/meta/recipes-core/busybox/busybox/0001-Allow-overriding-of-host-compiler-names.patch
new file mode 100644
index 0000000..9df0035
--- /dev/null
+++ b/meta/recipes-core/busybox/busybox/0001-Allow-overriding-of-host-compiler-names.patch
@@ -0,0 +1,27 @@
+From a4dc894195ccf58b60e867a170c27f6a4747b094 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?J=C3=A9r=C3=A9my=20Rosen?= <jeremy.rosen@smile.fr>
+Date: Wed, 17 Aug 2016 22:30:48 +0200
+Subject: [PATCH] Allow overriding of host compiler names
+
+---
+ Makefile | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/Makefile b/Makefile
+index 064d037..d1c4494 100644
+--- a/Makefile
++++ b/Makefile
+@@ -271,8 +271,8 @@ export quiet Q KBUILD_VERBOSE
+ # Look for make include files relative to root of kernel src
+ MAKEFLAGS += --include-dir=$(srctree)
+ 
+-HOSTCC  	= gcc
+-HOSTCXX  	= g++
++HOSTCC  	?= gcc
++HOSTCXX  	?= g++
+ HOSTCFLAGS	:=
+ HOSTCXXFLAGS	:=
+ # We need some generic definitions
+-- 
+2.8.1
+
-- 
git-series 0.8.9

[PATCH 7/8] [sanity] fix hardcoded references to gcc

[Jérémy Rosen]

Signed-off-by: Jérémy Rosen <jeremy.rosen@smile.fr>
---
 meta/classes/sanity.bbclass | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/meta/classes/sanity.bbclass b/meta/classes/sanity.bbclass
index 202b5db..f17e2d4 100644
--- a/meta/classes/sanity.bbclass
+++ b/meta/classes/sanity.bbclass
@@ -459,19 +459,19 @@ def check_gcc_march(sanity_data):
 
         # Check if GCC could work without march
         if not result:
-            status,res = oe.utils.getstatusoutput(sanity_data.expand("${BUILD_PREFIX}gcc gcc_test.c -o gcc_test"))
+            status,res = oe.utils.getstatusoutput(sanity_data.expand("${BUILD_CC} gcc_test.c -o gcc_test"))
             if status == 0:
                 result = True;
 
         if not result:
-            status,res = oe.utils.getstatusoutput(sanity_data.expand("${BUILD_PREFIX}gcc -march=native gcc_test.c -o gcc_test"))
+            status,res = oe.utils.getstatusoutput(sanity_data.expand("${BUILD_CC} -march=native gcc_test.c -o gcc_test"))
             if status == 0:
                 message = "BUILD_CFLAGS_append = \" -march=native\""
                 result = True;
 
         if not result:
             build_arch = sanity_data.getVar('BUILD_ARCH', True)
-            status,res = oe.utils.getstatusoutput(sanity_data.expand("${BUILD_PREFIX}gcc -march=%s gcc_test.c -o gcc_test" % build_arch))
+            status,res = oe.utils.getstatusoutput(sanity_data.expand("${BUILD_CC} -march=%s gcc_test.c -o gcc_test" % build_arch))
             if status == 0:
                 message = "BUILD_CFLAGS_append = \" -march=%s\"" % build_arch
                 result = True;
@@ -673,11 +673,11 @@ def check_sanity_version_change(status, d):
     if not check_app_exists("${MAKE}", d):
         missing = missing + "GNU make,"
 
-    if not check_app_exists('${BUILD_PREFIX}gcc', d):
-        missing = missing + "C Compiler (%sgcc)," % d.getVar("BUILD_PREFIX", True)
+    if not check_app_exists('${BUILD_CC}', d):
+        missing = missing + "C Compiler (%s)," % d.getVar("BUILD_CC", True)
 
-    if not check_app_exists('${BUILD_PREFIX}g++', d):
-        missing = missing + "C++ Compiler (%sg++)," % d.getVar("BUILD_PREFIX", True)
+    if not check_app_exists('${BUILD_CXX}', d):
+        missing = missing + "C++ Compiler (%s)," % d.getVar("BUILD_CXX", True)
 
     required_utilities = d.getVar('SANITY_REQUIRED_UTILITIES', True)
 
-- 
git-series 0.8.9

Re: [PATCH 7/8] [sanity] fix hardcoded references to gcc

[Burton, Ross]

[-- Attachment #1: Type: text/plain, Size: 860 bytes --]

On 23 August 2016 at 08:25, Jérémy Rosen <jeremy.rosen@smile.fr> wrote:

> Signed-off-by: Jérémy Rosen <jeremy.rosen@smile.fr>
>

Did you test this patch with a totally clean build directory?

ross@flashheart ~/Yocto/poky/boofo (mut %)
$ bitbake m4
ERROR:  OE-core's config sanity checker detected a potential
misconfiguration.
    Either fix the cause of this error or at your own risk disable the
checker (see sanity.conf).
    Following is the list of potential problems / advisories:

    Please install the following missing utilities: C Compiler (gcc ),C++
Compiler (g++ )

I think this is because BUILD_CC by default contains whitespace, and
bb.utils.which looks for "gcc ".  I added a strip() to check_app_exists and
it passed, so can you please verify that your series doesn't regress when
BUILD_CC isn't overridden?

Ross

[-- Attachment #2: Type: text/html, Size: 1708 bytes --]

Re: [PATCH 7/8] [sanity] fix hardcoded references to gcc

[Burton, Ross]

[-- Attachment #1: Type: text/plain, Size: 540 bytes --]

On 23 August 2016 at 15:53, Burton, Ross <ross.burton@intel.com> wrote:

> I think this is because BUILD_CC by default contains whitespace, and
> bb.utils.which looks for "gcc ".  I added a strip() to check_app_exists and
> it passed, so can you please verify that your series doesn't regress when
> BUILD_CC isn't overridden?
>

Patch sent to fix check_app_exists().  It currently just strips whitespace
and doesn't handle someone passing "foo --bar" to check_app_exists but this
is still a step in the right direction.

Ross

[-- Attachment #2: Type: text/html, Size: 929 bytes --]

Re: [PATCH 7/8] [sanity] fix hardcoded references to gcc

[Jérémy Rosen]

[-- Attachment #1: Type: text/plain, Size: 737 bytes --]



On 23/08/2016 17:11, Burton, Ross wrote:
>
> On 23 August 2016 at 15:53, Burton, Ross <ross.burton@intel.com 
> <mailto:ross.burton@intel.com>> wrote:
>
>     I think this is because BUILD_CC by default contains whitespace,
>     and bb.utils.which looks for "gcc ".  I added a strip() to
>     check_app_exists and it passed, so can you please verify that your
>     series doesn't regress when BUILD_CC isn't overridden?
>
>
> Patch sent to fix check_app_exists().  It currently just strips 
> whitespace and doesn't handle someone passing "foo --bar" to 
> check_app_exists but this is still a step in the right direction.
>
will do, but rebuilding from scratch is always long... so not right away :)
> Ross
>


[-- Attachment #2: Type: text/html, Size: 2098 bytes --]

Re: [PATCH 7/8] [sanity] fix hardcoded references to gcc

[Jérémy Rosen]

[-- Attachment #1: Type: text/plain, Size: 1094 bytes --]



On 23/08/2016 17:40, Jérémy Rosen wrote:
>
>
>
> On 23/08/2016 17:11, Burton, Ross wrote:
>>
>> On 23 August 2016 at 15:53, Burton, Ross <ross.burton@intel.com 
>> <mailto:ross.burton@intel.com>> wrote:
>>
>>     I think this is because BUILD_CC by default contains whitespace,
>>     and bb.utils.which looks for "gcc ".  I added a strip() to
>>     check_app_exists and it passed, so can you please verify that
>>     your series doesn't regress when BUILD_CC isn't overridden?
>>
>>
>> Patch sent to fix check_app_exists().  It currently just strips 
>> whitespace and doesn't handle someone passing "foo --bar" to 
>> check_app_exists but this is still a step in the right direction.
>>
> will do, but rebuilding from scratch is always long... so not right 
> away :)

and... done. I do indeed need your patch to get this working, but it 
works correctly.
since I need to get a patch upstream in glibc V2 of this serie won't be 
here right away. Hopefully your patch will be accepted at that point 
(I'll check that before sending V2)
>> Ross
>>
>
>
>


[-- Attachment #2: Type: text/html, Size: 3071 bytes --]

[PATCH 8/8] [glibc] remove hard-coded reference to gcc -E

[Jérémy Rosen]

Signed-off-by: Jérémy Rosen <jeremy.rosen@smile.fr>
---
 meta/recipes-core/glibc/glibc/0001-locale-fix-hard-coded-reference-to-gcc-E.patch | 23 +++++++++++++++++++++++
 meta/recipes-core/glibc/glibc_2.24.bb                                             |  6 ++----
 2 files changed, 25 insertions(+), 4 deletions(-)
 create mode 100644 meta/recipes-core/glibc/glibc/0001-locale-fix-hard-coded-reference-to-gcc-E.patch

diff --git a/meta/recipes-core/glibc/glibc/0001-locale-fix-hard-coded-reference-to-gcc-E.patch b/meta/recipes-core/glibc/glibc/0001-locale-fix-hard-coded-reference-to-gcc-E.patch
new file mode 100644
index 0000000..8fe681f
--- /dev/null
+++ b/meta/recipes-core/glibc/glibc/0001-locale-fix-hard-coded-reference-to-gcc-E.patch
@@ -0,0 +1,23 @@
+From 2c0ab83eb54c0e0fccbf261726dc03803b236079 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?J=C3=A9r=C3=A9my=20Rosen?= <jeremy.rosen@smile.fr>
+Date: Mon, 22 Aug 2016 16:09:25 +0200
+Subject: [PATCH] locale: fix hard-coded reference to gcc -E
+
+---
+ locale/gen-translit.pl | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/locale/gen-translit.pl b/locale/gen-translit.pl
+index 30d3f2f..7b287fa 100644
+--- a/locale/gen-translit.pl
++++ b/locale/gen-translit.pl
+@@ -1,5 +1,5 @@
+ #!/usr/bin/perl -w
+-open F, "cat C-translit.h.in | gcc -E - |" || die "Cannot preprocess input file";
++open F, 'cat C-translit.h.in | $CPP - |' || die "Cannot preprocess input file";
+ 
+ 
+ sub cstrlen {
+-- 
+2.9.3
+
diff --git a/meta/recipes-core/glibc/glibc_2.24.bb b/meta/recipes-core/glibc/glibc_2.24.bb
index e446e7a..a15c323 100644
--- a/meta/recipes-core/glibc/glibc_2.24.bb
+++ b/meta/recipes-core/glibc/glibc_2.24.bb
@@ -36,12 +36,10 @@ SRC_URI = "${GLIBC_GIT_URI};branch=${SRCBRANCH};name=glibc \
            file://0023-eglibc-Install-PIC-archives.patch \
            file://0024-eglibc-Forward-port-cross-locale-generation-support.patch \
            file://0025-Define-DUMMY_LOCALE_T-if-not-defined.patch \
-"
-
-SRC_URI += "\
            file://etc/ld.so.conf \
            file://generate-supported.mk \
-"
+           file://0001-locale-fix-hard-coded-reference-to-gcc-E.patch \
+           "
 
 SRC_URI_append_class-nativesdk = "\
            file://0001-nativesdk-glibc-Look-for-host-system-ld.so.cache-as-.patch \
-- 
git-series 0.8.9

Re: [PATCH 8/8] [glibc] remove hard-coded reference to gcc -E

[Burton, Ross]

[-- Attachment #1: Type: text/plain, Size: 443 bytes --]

On 23 August 2016 at 08:25, Jérémy Rosen <jeremy.rosen@smile.fr> wrote:

> +-open F, "cat C-translit.h.in | gcc -E - |" || die "Cannot preprocess
> input file";
> ++open F, 'cat C-translit.h.in | $CPP - |' || die "Cannot preprocess
> input file";
>

Patch is missing an Upstream-Status, and I expect if you allowed for CPP to
be unset then there's a chance you can get this upstream.

${CPP:-gcc -E} should do the trick.

Ross

[-- Attachment #2: Type: text/html, Size: 1123 bytes --]

Re: [PATCH 8/8] [glibc] remove hard-coded reference to gcc -E

[Jérémy Rosen]

[-- Attachment #1: Type: text/plain, Size: 764 bytes --]



On 23/08/2016 16:03, Burton, Ross wrote:
>
> On 23 August 2016 at 08:25, Jérémy Rosen <jeremy.rosen@smile.fr 
> <mailto:jeremy.rosen@smile.fr>> wrote:
>
>     +-open F, "cat C-translit.h.in <http://C-translit.h.in> | gcc -E -
>     |" || die "Cannot preprocess input file";
>     ++open F, 'cat C-translit.h.in <http://C-translit.h.in> | $CPP -
>     |' || die "Cannot preprocess input file";
>
>
> Patch is missing an Upstream-Status, and I expect if you allowed for 
> CPP to be unset then there's a chance you can get this upstream.
>
> ${CPP:-gcc -E} should do the trick.
>
I'm currently discussing with upstream. That script is theoretically 
only called by a Makefile that sets $CPP, but yes, that is a good 
suggestion.

> Ross


[-- Attachment #2: Type: text/html, Size: 2324 bytes --]