Re: [OE-core] [PATCH v2 2/3] image_overlay.bbclass: Add possibility to install overlays to image

2017-02-17 Thread Jérémy Rosen



On 16/02/2017 05:44, Richard Purdie wrote:

On Wed, 2017-02-15 at 18:33 +0100, Geoffrey Levillain wrote:

There is often a need to add configuration files specific to an
image,
to simplify this process we can use a task.

Fetching is set as noexec for images, but there is a need to fetch
files
here. This class permit to use do_fetch, do_unpack and do_patch in
order
to get your image-specific overlays to install.

Signed-off-by: Geoffrey Levillain <geoffrey.levill...@smile.fr>
---
  meta/classes/image_overlay.bbclass | 24 
  1 file changed, 24 insertions(+)
  create mode 100644 meta/classes/image_overlay.bbclass

diff --git a/meta/classes/image_overlay.bbclass
b/meta/classes/image_overlay.bbclass
new file mode 100644
index 00..93c1ea6f9f
--- /dev/null
+++ b/meta/classes/image_overlay.bbclass
@@ -0,0 +1,24 @@
+# Enable SRC_URI for images and use it to install overlays
+
+# Let these task be executed to fetch overlay
+unset do_fetch[noexec]
+unset do_unpack[noexec]
+unset do_patch[noexec]

At the same time as you're submitting this, I'm seriously considering a
change where instead of noexec, we'd deltask these tasks. The reason
being I'm not very keen on subverting the package manager and I'm not
convinced this is a particularly desirable way to be altering the
rootfs.
There are various files in images that are provided by the package 
manager and that are ok to modify. most files in /etc are in that category.


The idea here is to be able to have generic (image independant) 
packages, but to override the package configuration with custom ones at 
image-generation time.


on a normal (desktop) distribution, the user writes his configuration 
files, but in a deep-embedded useage, there is no user.


A bbappend (overriding the config file at package-build time) would seem 
a better solution at first, but this doesn't work because it forces to 
have a different package for each image type. Again we are trying to 
particularize each image, while keeping the distribution itself generic.


I hope this helps clarify why we do this at the image level and not the 
package. packages are shared between images, but configuration is 
altered per-image.


Jérémy


+# Add a task to install the overlay
+# (content of folders listed in OVERLAY_ROOT_DIRS is copied in
rootfs)
+addtask install_overlay after do_unpack do_patch do_rootfs before
do_image
+fakeroot do_install_overlay() {
+for dir in ${OVERLAY_ROOT_DIRS}; do
+if [ ! -d "${WORKDIR}/${dir}" ] ; then
+bbfatal "${dir} not found, please check your
OVERLAY_ROOT_DIRS and SRC_URI variables."
+fi
+cp -dr --no-preserve=ownership "${WORKDIR}/${dir}"/*
"${IMAGE_ROOTFS}"
+done
+}
+do_install_overlay[depends] += "virtual/fakeroot-
native:do_populate_sysroot"
+do_install_overlay[dirs] = "${IMAGE_ROOTFS}"
+do_install_overlay[umask] = "022"
+do_install_overlay[vardeps] += "OVERLAY_ROOT_DIRS"
+
+SSTATETASKS += "do_install_overlay"

Except this isn't an sstate task? There is no setscene task variant of
the main task. There are no sstate variables set either...

Cheers,

Richard





--
Logo <http://www.smile.fr/>

20 rue des Jardins
92600 Asnières-sur-Seine
www.smile.fr <http://www.smile.fr/>   
*Jérémy ROSEN*
Architecte technique
Email : jeremy.ro...@smile.fr <mailto:jeremy.ro...@smile.fr>
Tel : +33141402967

Facebook <https://www.facebook.com/smileopensource> Google%2B 
<http://fr.slideshare.net/SmileOpenSource/presentations> LinkedIn 
<https://www.linkedin.com/company/smile> Twitter 
<https://twitter.com/GroupeSmile>



bandeaux_mail 
<http://www.smile.fr/Offres-services/Offres/Ingenierie?utm_source=signature_medium=email_campaign=signature>


eco Pour la planète, n'imprimez ce mail que si c'est nécessaire
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


Re: [OE-core] [PATCH v2 0/3] Permit to install files from an overlay in images recipes

2017-02-17 Thread Jérémy Rosen



On 16/02/2017 03:18, Gary Thomas wrote:

On 2017-02-15 18:33, Geoffrey Levillain wrote:

Hi,

These patches introduce a capability to install overlay into image after
fetching them.

There is actually a need to add image-specific configurations files into
image recipes, and these patches are a way to standardize this 
process as

well as simplify it by re-enabling fetching when image_overlay is
inherited, and by providing a task that copy every files in directories
listed in OVERLAY_ROOT_DIRS into IMAGE_ROOTFS directory.

Geoffrey Levillain (3):
  image.bbclass: No need to force image licence on MIT
  image_overlay.bbclass: Add possibility to install overlays to image
  rm_work.bbclass: Do not remove fetching and install_overlay stamps

 meta/classes/image.bbclass |  2 +-
 meta/classes/image_overlay.bbclass | 24 
 meta/classes/rm_work.bbclass   |  4 
 3 files changed, 29 insertions(+), 1 deletion(-)
 create mode 100644 meta/classes/image_overlay.bbclass


Can you give an example where this approach is better than just
having the image include some [possibly optional] packages that
contain these image-specific configuration files?

The problem is that most configuration files are provided by a package 
and thus can not be overriden by another package.
(a bbappend for each package we want to modify is a big amount of 
tweaking and would force a variant of the package for each image with a 
different configuration)
A "configuration package" can only add new conf files, it can't alter 
existing files.


Regards
Jérémy

--
Logo <http://www.smile.fr/>

20 rue des Jardins
92600 Asnières-sur-Seine
www.smile.fr <http://www.smile.fr/>   
*Jérémy ROSEN*
Architecte technique
Email : jeremy.ro...@smile.fr <mailto:jeremy.ro...@smile.fr>
Tel : +33141402967

Facebook <https://www.facebook.com/smileopensource> Google%2B 
<http://fr.slideshare.net/SmileOpenSource/presentations> LinkedIn 
<https://www.linkedin.com/company/smile> Twitter 
<https://twitter.com/GroupeSmile>



bandeaux_mail 
<http://www.smile.fr/Offres-services/Offres/Ingenierie?utm_source=signature_medium=email_campaign=signature>


eco Pour la planète, n'imprimez ce mail que si c'est nécessaire
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


Re: [OE-core] [PATCH v2] scripts: add new script 'native'

2016-10-02 Thread Jérémy Rosen

"native" might be a bit too generic...

could I suggest oe_native-run or bitbake-native ?

something that says it's yocto-galaxy specific and can be autocompleted 
with a reasonable prefix...



Jérémy Rosen


On 30/09/2016 17:02, Ed Bartosh wrote:

Added 'native' convenience shell script to run native tools.
Example of usage:
   > bitbake bmap-tools-native
   > native bmaptool --version

Signed-off-by: Ed Bartosh <ed.bart...@linux.intel.com>
---
  scripts/native | 48 
  1 file changed, 48 insertions(+)
  create mode 100755 scripts/native

diff --git a/scripts/native b/scripts/native
new file mode 100755
index 000..496e34f
--- /dev/null
+++ b/scripts/native
@@ -0,0 +1,48 @@
+#!/bin/sh
+#
+# Copyright (c) 2016,  Intel Corporation.
+# All Rights Reserved
+#
+# This program is free software;  you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2 of the License, or
+# (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY;  without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See
+# the GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program;  if not, see <http://www.gnu.org/licenses/>
+#
+
+#
+# This script is for running tools from native oe sysroot
+#
+
+if [ $# -lt 1 -o "$1" = '--help' -o "$1" = '-h' ] ; then
+echo "Usage: $0  [parameters]"
+exit 1
+fi
+
+SYSROOT_SETUP_SCRIPT=`which oe-find-native-sysroot 2> /dev/null`
+if [ -z "$SYSROOT_SETUP_SCRIPT" ]; then
+echo "Error: Unable to find oe-find-native-sysroot script"
+exit 1
+fi
+. $SYSROOT_SETUP_SCRIPT
+
+OLDPATH=$PATH
+
+# look for a tool only in native sysroot
+PATH=$OECORE_NATIVE_SYSROOT/usr/bin:$OECORE_NATIVE_SYSROOT/bin:$OECORE_NATIVE_SYSROOT/usr/sbin:$OECORE_NATIVE_SYSROOT/sbin
+tool=`/usr/bin/which $1 2>/dev/null`
+
+if [ -n "$tool" ] ; then
+# add old path to allow usage of host tools
+PATH=$PATH:$OLD_PATH $@
+else
+echo "Error: Unable to find '$1' in native sysroot"
+exit 1
+fi


--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


Re: [OE-core] [PATCH v2 0/8] Fix BUILD_* family of variables

2016-09-12 Thread Jérémy Rosen



On 12/09/2016 17:22, Burton, Ross wrote:
It's in my staging branch and works for me, just needs a run through 
the AB and then a decision on whether it is a bug fix (good for M4) or 
enhancement (too late for M3)...



If I can weight on that one

it's technically a bug-fix, but the fix is only usefull in the far 
future, once gcc-7 is out and current master is in maintainence mode and 
doesn't compile with gcc-7

so no need to rush it in.

However that serie is probably usefull on krogoth and definitely usefull 
on jethro. (I originally made it for jethro) so if it needs to be 
accepted to allow backporting, maybe it's worth rushing it...



Ross

On 12 September 2016 at 16:19, Jérémy Rosen <jeremy.ro...@smile.fr 
<mailto:jeremy.ro...@smile.fr>> wrote:


Any news ?



On 07/09/2016 11:08, Jérémy Rosen wrote:

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"

---
V2
* rewording in some commits messages
* no need for a patch to KConfig, use OE_RUNMAKE_FLAGS instead
* change all patch titles to use : in the short commit message
* rpm : manually remove files instead of calling make distclean
* libpcre : explicitely set CCLD_FOR_BUILD in the recipe since
it's the only
   recipe using it.
* glibc patch has been submited upstream

It would 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):
   cross: export CC family from BUILD_* for cross compilers
   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
   rpm: manually cleanup sysck
   libpcre: explicitely specify CCLD_FOR_BUILD for this recipe

  meta/classes/cross.bbclass   |
12 
  meta/classes/kernel.bbclass  |  1 +
  meta/classes/sanity.bbclass  |
14 +++---
  meta/recipes-core/busybox/busybox.inc  
 |  2 +-
 
meta/recipes-core/glibc/glibc/0001-locale-fix-hard-coded-reference-to-gcc-E.patch

| 39 +++
  meta/recipes-core/glibc/glibc_2.24.bb <http://glibc_2.24.bb>
   |  3 ++-
  meta/recipes-devtools/rpm/rpm_5.4.16.bb
<http://rpm_5.4.16.bb>  |  2 +-
 
meta/recipes-kernel/linux-libc-headers/linux-libc-headers.inc

   |  2 ++
  meta/recipes-support/libpcre/libpcre_8.39.bb
<http://libpcre_8.39.bb>
|  2 ++

  9 files changed, 67 insertions(+), 10 deletions(-)
  create mode 100644

meta/recipes-core/glibc/glibc/0001-locale-fix-hard-coded-reference-to-gcc-E.patch


-- 
___

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/mai

Re: [OE-core] [PATCH v2 0/8] Fix BUILD_* family of variables

2016-09-12 Thread Jérémy Rosen

Any news ?


On 07/09/2016 11:08, Jérémy Rosen wrote:

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"

---
V2
* rewording in some commits messages
* no need for a patch to KConfig, use OE_RUNMAKE_FLAGS instead
* change all patch titles to use : in the short commit message
* rpm : manually remove files instead of calling make distclean
* libpcre : explicitely set CCLD_FOR_BUILD in the recipe since it's the only
   recipe using it.
* glibc patch has been submited upstream

It would 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):
   cross: export CC family from BUILD_* for cross compilers
   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
   rpm: manually cleanup sysck
   libpcre: explicitely specify CCLD_FOR_BUILD for this recipe

  meta/classes/cross.bbclass
| 12 
  meta/classes/kernel.bbclass   
|  1 +
  meta/classes/sanity.bbclass   
| 14 +++---
  meta/recipes-core/busybox/busybox.inc 
|  2 +-
  
meta/recipes-core/glibc/glibc/0001-locale-fix-hard-coded-reference-to-gcc-E.patch
 | 39 +++
  meta/recipes-core/glibc/glibc_2.24.bb 
|  3 ++-
  meta/recipes-devtools/rpm/rpm_5.4.16.bb   
|  2 +-
  meta/recipes-kernel/linux-libc-headers/linux-libc-headers.inc 
|  2 ++
  meta/recipes-support/libpcre/libpcre_8.39.bb  
|  2 ++
  9 files changed, 67 insertions(+), 10 deletions(-)
  create mode 100644 
meta/recipes-core/glibc/glibc/0001-locale-fix-hard-coded-reference-to-gcc-E.patch



--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


Re: [OE-core] [PATCH 0/3] systemd: add support to manage user units

2016-09-07 Thread Jérémy Rosen
It's probably worth updating the documentation too... this is a usefull 
feature and it deserves the exposure



Regards

Jeremy Rosen


On 07/09/2016 11:22, Chen Qi wrote:

The following changes since commit 55bb6816aca39bfa25d4f7e2158a57a5f0ac1cca:

   oeqa.buildperf: correct globalres time format (2016-09-06 10:24:00 +0100)

are available in the git repository at:

   git://git.openembedded.org/openembedded-core-contrib 
ChenQi/systemd-user-units
   
http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=ChenQi/systemd-user-units

Chen Qi (3):
   systemd-systemctl: add option to manage user services
   systemd.bbclass: add support to manage user services
   pulseaudio: fix to manage user services corretly

  meta/classes/systemd.bbclass   | 17 ++--
  .../systemd/systemd-systemctl/systemctl| 45 ++
  meta/recipes-multimedia/pulseaudio/pulseaudio.inc  |  4 +-
  3 files changed, 43 insertions(+), 23 deletions(-)



--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


[OE-core] [PATCH v2 8/8] libpcre: explicitely specify CCLD_FOR_BUILD for this recipe

2016-09-07 Thread Jérémy Rosen
libpcre uses CCLD_FOR_BUILD as the name of the host command to use for
linking. This is not a standard autotools symbol but particular to this
recipe. We need to set it explicitely

Signed-off-by: Jérémy Rosen <jeremy.ro...@smile.fr>
---
 meta/recipes-support/libpcre/libpcre_8.39.bb | 2 ++
 1 file changed, 2 insertions(+), 0 deletions(-)

diff --git a/meta/recipes-support/libpcre/libpcre_8.39.bb 
b/meta/recipes-support/libpcre/libpcre_8.39.bb
index 129076a..2d4668b 100644
--- a/meta/recipes-support/libpcre/libpcre_8.39.bb
+++ b/meta/recipes-support/libpcre/libpcre_8.39.bb
@@ -48,6 +48,8 @@ BUILD_CFLAGS =+ "-DLINK_SIZE=2 -I${B}"
 CFLAGS += "-D_REENTRANT"
 CXXFLAGS_append_powerpc = " -lstdc++"
 
+export CCLD_FOR_BUILD ="${BUILD_CCLD}"
+
 PACKAGES =+ "libpcrecpp libpcreposix pcregrep pcregrep-doc pcretest 
pcretest-doc"
 
 SUMMARY_libpcrecpp = "${SUMMARY} - C++ wrapper functions"
-- 
git-series 0.8.9
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


[OE-core] [PATCH v2 6/8] glibc: remove hard-coded reference to gcc -E

2016-09-07 Thread Jérémy Rosen
Signed-off-by: Jérémy Rosen <jeremy.ro...@smile.fr>
---
 
meta/recipes-core/glibc/glibc/0001-locale-fix-hard-coded-reference-to-gcc-E.patch
 | 39 +++
 meta/recipes-core/glibc/glibc_2.24.bb  
   |  3 ++-
 2 files changed, 41 insertions(+), 1 deletion(-)
 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 000..d5fce73
--- /dev/null
+++ 
b/meta/recipes-core/glibc/glibc/0001-locale-fix-hard-coded-reference-to-gcc-E.patch
@@ -0,0 +1,39 @@
+From 2c0ab83eb54c0e0fccbf261726dc03803b236079 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?J=C3=A9r=C3=A9my=20Rosen?= <jeremy.ro...@smile.fr>
+Date: Mon, 22 Aug 2016 16:09:25 +0200
+Subject: [PATCH] locale: fix hard-coded reference to gcc -E
+
+When new version of compilers are published, they may not be compatible with 
+older versions of software. This is particularly common when software is built
+with -Werror.
+
+Autotools provides a way for a user to specify the name of his compiler using a
+set of variables ($CC $CXX $CPP etc.). Those variables are used correctly when
+compiling glibc but the script used to generate transliterations in the locale/
+subdirectory directly calls the gcc binary to get the output of the 
+preprocessor instead of using the $CPP variable provided by the build 
+environment. 
+
+This patch replaces the hard-coded reference to the gcc binary with the proper
+environment variable, thus allowing a user to override it.
+
+Upstream-Status : Submitted 
[https://sourceware.org/ml/libc-alpha/2016-08/msg00746.html]
+
+---
+ 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:-gcc -E} - |' || 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 a3ac738..f5a21b2 100644
--- a/meta/recipes-core/glibc/glibc_2.24.bb
+++ b/meta/recipes-core/glibc/glibc_2.24.bb
@@ -42,7 +42,8 @@ SRC_URI = "${GLIBC_GIT_URI};branch=${SRCBRANCH};name=glibc \
 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
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


[OE-core] [PATCH v2 7/8] rpm: manually cleanup sysck

2016-09-07 Thread Jérémy Rosen
version 5.4.1 of rpm was not properly distclean before release, which
causes problems when cross-compiling.

The previous version this recipe called make distclean, but that would
trigger a call to ./configure which would fail when no gcc is
available and make the whole do_configure fail further down the line

This patch manually removes the files from the recipe.

Signed-off-by: Jérémy Rosen <jeremy.ro...@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 55acd25..9f78dee 100644
--- a/meta/recipes-devtools/rpm/rpm_5.4.16.bb
+++ b/meta/recipes-devtools/rpm/rpm_5.4.16.bb
@@ -527,7 +527,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* ; rm Makefile config.h 
config.status lib/Makefile libtool stamp-h1 tests/.deps tests/Makefile  ) || :
 
export varprefix=${localstatedir}
oe_runconf
-- 
git-series 0.8.9
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


[OE-core] [PATCH v2 4/8] busybox: allow overriding compiler name in KConfig

2016-09-07 Thread Jérémy Rosen
The KConfig infrastructure needs to build HOST binaries in order to
provide its infratstructure. Yocto needs to force the HOSTCC and HOSTCPP
variables to BUILD_CC and BUILD_CPP to make sure that the proper compiler
is used when compiling host binaries
---
 meta/recipes-core/busybox/busybox.inc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-core/busybox/busybox.inc 
b/meta/recipes-core/busybox/busybox.inc
index 39c2eef..f67bbbc 100644
--- a/meta/recipes-core/busybox/busybox.inc
+++ b/meta/recipes-core/busybox/busybox.inc
@@ -19,7 +19,7 @@ export EXTRA_CFLAGS = "${CFLAGS}"
 export EXTRA_LDFLAGS = "${LDFLAGS}"
 
 # We don't want '-e MAKEFLAGS=' in EXTRA_OEMAKE
-EXTRA_OEMAKE = "CC='${CC}' LD='${CCLD}' V=1 ARCH=${TARGET_ARCH} 
CROSS_COMPILE=${TARGET_PREFIX} SKIP_STRIP=y"
+EXTRA_OEMAKE = "CC='${CC}' LD='${CCLD}' V=1 ARCH=${TARGET_ARCH} 
CROSS_COMPILE=${TARGET_PREFIX} SKIP_STRIP=y HOSTCC='${BUILD_CC}' 
HOSTCPP='${BUILD_CPP}'"
 
 PACKAGES =+ "${PN}-httpd ${PN}-udhcpd ${PN}-udhcpc ${PN}-syslog ${PN}-mdev 
${PN}-hwclock"
 
-- 
git-series 0.8.9
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


[OE-core] [PATCH v2 5/8] sanity: fix hardcoded references to gcc

2016-09-07 Thread Jérémy Rosen
Signed-off-by: Jérémy Rosen <jeremy.ro...@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
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


[OE-core] [PATCH v2 3/8] linux-libc-headers: allow overriding compiler name in KConfig

2016-09-07 Thread Jérémy Rosen
The KConfig infrastructure needs to build HOST binaries in order to
provide its infratstructure. Yocto needs to force the HOSTCC and HOSTCPP
variables to BUILD_CC and BUILD_CPP to make sure that the proper compiler
is used when compiling host binaries
---
 meta/recipes-kernel/linux-libc-headers/linux-libc-headers.inc | 2 ++
 1 file changed, 2 insertions(+), 0 deletions(-)

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 c701b39..078d752 100644
--- a/meta/recipes-kernel/linux-libc-headers/linux-libc-headers.inc
+++ b/meta/recipes-kernel/linux-libc-headers/linux-libc-headers.inc
@@ -50,6 +50,8 @@ SRC_URI = 
"${KERNELORG_MIRROR}/linux/kernel/v${HEADER_FETCH_VER}/linux-${PV}.tar
 
 S = "${WORKDIR}/linux-${PV}"
 
+EXTRA_OEMAKE = " HOSTCC="${BUILD_CC}" HOSTCPP="${BUILD_CPP}""
+
 do_configure() {
oe_runmake allnoconfig
 }
-- 
git-series 0.8.9
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


[OE-core] [PATCH v2 0/8] Fix BUILD_* family of variables

2016-09-07 Thread 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"

---
V2
* rewording in some commits messages
* no need for a patch to KConfig, use OE_RUNMAKE_FLAGS instead
* change all patch titles to use : in the short commit message
* rpm : manually remove files instead of calling make distclean
* libpcre : explicitely set CCLD_FOR_BUILD in the recipe since it's the only
  recipe using it.
* glibc patch has been submited upstream

It would 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):
  cross: export CC family from BUILD_* for cross compilers
  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
  rpm: manually cleanup sysck
  libpcre: explicitely specify CCLD_FOR_BUILD for this recipe

 meta/classes/cross.bbclass 
   | 12 
 meta/classes/kernel.bbclass
   |  1 +
 meta/classes/sanity.bbclass
   | 14 +++---
 meta/recipes-core/busybox/busybox.inc  
   |  2 +-
 
meta/recipes-core/glibc/glibc/0001-locale-fix-hard-coded-reference-to-gcc-E.patch
 | 39 +++
 meta/recipes-core/glibc/glibc_2.24.bb  
   |  3 ++-
 meta/recipes-devtools/rpm/rpm_5.4.16.bb
   |  2 +-
 meta/recipes-kernel/linux-libc-headers/linux-libc-headers.inc  
   |  2 ++
 meta/recipes-support/libpcre/libpcre_8.39.bb   
   |  2 ++
 9 files changed, 67 insertions(+), 10 deletions(-)
 create mode 100644 
meta/recipes-core/glibc/glibc/0001-locale-fix-hard-coded-reference-to-gcc-E.patch

-- 
git-series 0.8.9
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


[OE-core] [PATCH v2 1/8] cross: export CC family from BUILD_* for cross compilers

2016-09-07 Thread Jérémy Rosen
cross-compilers are native recipes that need to be compiled by the host's
compiler. However they 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.ro...@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


[OE-core] [PATCH v2 2/8] linux-yocto: allow overriding compiler name in KConfig

2016-09-07 Thread Jérémy Rosen
The KConfig infrastructure needs to build HOST binaries in order to
provide its infratstructure. Yocto needs to force the HOSTCC and HOSTCPP
variables to BUILD_CC and BUILD_CPP to make sure that the proper compiler
is used when compiling host binaries
---
 meta/classes/kernel.bbclass | 1 +
 1 file changed, 1 insertion(+), 0 deletions(-)

diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index d6a0ca8..e4e8ee4 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -156,6 +156,7 @@ UBOOT_LOADADDRESS ?= "${UBOOT_ENTRYPOINT}"
 # Some Linux kernel configurations need additional parameters on the command 
line
 KERNEL_EXTRA_ARGS ?= ""
 
+EXTRA_OEMAKE = " HOSTCC="${BUILD_CC}" HOSTCPP="${BUILD_CPP}""
 KERNEL_ALT_IMAGETYPE ??= ""
 
 copy_initramfs() {
-- 
git-series 0.8.9
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


Re: [OE-core] [PATCH 1/8] [autotools] export CCLD_FOR_BUILD

2016-08-25 Thread Jérémy Rosen



On 24/08/2016 21:56, Burton, Ross wrote:


On 24 August 2016 at 12:28, Jérémy Rosen <jeremy.ro...@smile.fr 
<mailto:jeremy.ro...@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


-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


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

2016-08-24 Thread 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




--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


Re: [OE-core] [PATCH 1/8] [autotools] export CCLD_FOR_BUILD

2016-08-24 Thread 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




--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


Re: [OE-core] [PATCH 1/8] [autotools] export CCLD_FOR_BUILD

2016-08-24 Thread 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.ro...@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.ro...@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


--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


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

2016-08-24 Thread Jérémy Rosen



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.bur...@intel.com 
<mailto:ross.bur...@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







-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


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

2016-08-24 Thread Jérémy Rosen

[...]


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 


http://lists.openembedded.org/mailman/listinfo/openembedded-core




-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


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

2016-08-24 Thread 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.ro...@smile.fr
<mailto:jeremy.ro...@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




--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


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

2016-08-23 Thread Jérémy Rosen



On 23/08/2016 17:11, Burton, Ross wrote:


On 23 August 2016 at 15:53, Burton, Ross > 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



-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


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

2016-08-23 Thread Jérémy Rosen



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.ro...@smile.fr 
<mailto:jeremy.ro...@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.ro...@smile.fr
<mailto:jeremy.ro...@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>




-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


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

2016-08-23 Thread Jérémy Rosen



On 23/08/2016 16:03, Burton, Ross wrote:


On 23 August 2016 at 08:25, Jérémy Rosen <jeremy.ro...@smile.fr 
<mailto:jeremy.ro...@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


-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


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

2016-08-23 Thread Jérémy Rosen



On 23/08/2016 15:41, Bruce Ashfield wrote:



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


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

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

2016-08-23 Thread Jérémy Rosen



On 23/08/2016 15:36, Bruce Ashfield wrote:
On Tue, Aug 23, 2016 at 3:25 AM, Jérémy Rosen <jeremy.ro...@smile.fr 
<mailto:jeremy.ro...@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 000..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.ro...@smile.fr
<mailto:jeremy.ro...@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


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

2016-08-23 Thread 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 000..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?= 
+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


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

2016-08-23 Thread 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.ro...@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


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

2016-08-23 Thread Jérémy Rosen
Signed-off-by: Jérémy Rosen <jeremy.ro...@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 000..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.ro...@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
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


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

2016-08-23 Thread 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 000..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?= 
+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
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


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

2016-08-23 Thread Jérémy Rosen
Signed-off-by: Jérémy Rosen <jeremy.ro...@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
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


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

2016-08-23 Thread 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 000..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?= 
+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


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

2016-08-23 Thread 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
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


[OE-core] [PATCH 1/8] [autotools] export CCLD_FOR_BUILD

2016-08-23 Thread 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.ro...@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
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


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

2016-08-23 Thread 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.ro...@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
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


Re: [OE-core] what means IMAGE_ROOTFS_EXTRA_SPACE_append += "+ 3000000"?

2016-08-17 Thread Jérémy Rosen



On 17/08/2016 16:01, Robert P. J. Day wrote:

   as in, what's with the "+" in that "+ 300" value? i've never
seen that before, and i took a quick look under classes/ to try to
figure out what's happening, but i'm still confused.

you're reading too much into this

"+ 300" will append the string "+ 300" to the string contained 
in the IMAGE_ROOTFS_EXTRA_SPACE variable


I am not sure who consumes that variable, but I assume it's something 
that's able to do math and will properly compute the final value.


you can always run "bitbake -e core-image-kernel-dev" in a pager an look 
at the final value to see what's happening...



   this is all in aid of the aforementioned "+=" cleanup, and i can see
some inconsistency as to whether there should be a leading space or
not in the assigned value:

classes/rootfs_rpm.bbclass:IMAGE_ROOTFS_EXTRA_SPACE_append = "${@bb.utils.contains("PACKAGE_INSTALL", 
"smartpm", " + 102400", "" ,d)}"
recipes-core/images/core-image-minimal.bb:IMAGE_ROOTFS_EXTRA_SPACE_append = 
"${@bb.utils.contains("DISTRO_FEATURES", "systemd", " + 4096", "" ,d)}"
recipes-extended/images/core-image-kernel-dev.bb:IMAGE_ROOTFS_EXTRA_SPACE_append += 
"+ 300"

and the YP reference manual says nothing about a possible "+":

http://www.yoctoproject.org/docs/latest/ref-manual/ref-manual.html#var-IMAGE_ROOTFS_EXTRA_SPACE

rday



--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


[OE-core] [PATCH 1/1] init-live : make it easier to add custom boot targets

2016-03-11 Thread Jérémy Rosen
When booting from the live image, the label from the bootloader is passed
to init.sh. init.sh uses the label to either boot a live image or call a
script to take over and install the system.

It is possible to add new labels to the bootloader via the LABELS family of
variables, but the names in init.sh were hardcoded to install and
install-efi

this patch checks if a shell script with the same name as the label is
available instead of using a hardcoded list. Any recipe can add such file
and this provide a new boot target to the live image

Signed-off-by: Jérémy Rosen <jeremy.ro...@openwide.fr>
---
 meta/recipes-core/initrdscripts/files/init-live.sh | 18 ++
 1 file changed, 6 insertions(+), 12 deletions(-)

diff --git a/meta/recipes-core/initrdscripts/files/init-live.sh 
b/meta/recipes-core/initrdscripts/files/init-live.sh
index d852c57..f698535 100644
--- a/meta/recipes-core/initrdscripts/files/init-live.sh
+++ b/meta/recipes-core/initrdscripts/files/init-live.sh
@@ -214,11 +214,7 @@ mount_and_boot() {
 boot_live_root
 }
 
-case $label in
-boot)
-   mount_and_boot
-   ;;
-install|install-efi)
+if [ "$label" != "boot" -a -f $label.sh ] ; then
if [ -f /run/media/$i/$ISOLINUX/$ROOT_IMAGE ] ; then
./$label.sh $i/$ISOLINUX $ROOT_IMAGE $video_mode $vga_mode 
$console_params
else
@@ -226,10 +222,8 @@ case $label in
fi
 
# If we're getting here, we failed...
-   fatal "Installation image failed"
-   ;;
-*)
-   # Not sure what boot label is provided.  Try to boot to avoid locking 
up.
-   mount_and_boot
-   ;;
-esac
+   fatal "Target $label failed"
+fi
+
+mount_and_boot
+
-- 
2.7.0

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core