[OE-core] [morty][PATCH] elfutils: fix building elfutils-native with GCC7

2017-06-07 Thread Cody P Schafer 
This is heavily based on the oe-core master commit with the same
subject, but includes a backport of upstream's fix for the fallthrough
warnings rebased to 0.166 (the oe-core patch which targeted 0.168 did
not apply), a rebase of the format-truncation patch, and a backport of
the upstream format-length patch.

Info from OE-Core master patch follows:

From OE-Core rev: aaf4c4f3d09ac3897205417eb15e19d54e0c0d05
From: Joshua Lock 

Backport a fix from upstream for a -Wformat-truncation=2 warning
and implement a simple fix for a -Wimplicit-fallthrough warning.

Signed-off-by: Joshua Lock 
Signed-off-by: Richard Purdie 

Signed-off-by: Cody P Schafer 
---
 ...-GCC7-Wimplicit-fallthrough-support-fixes.patch | 318 +
 .../0001-ar-Fix-GCC7-Wformat-length-issues.patch   | 125 
 .../elfutils-0.166/Fix_one_GCC7_warning.patch  |  45 +++
 .../elfutils/elfutils-0.166/fallthrough.patch  |  36 +++
 meta/recipes-devtools/elfutils/elfutils_0.166.bb   |   5 +
 5 files changed, 529 insertions(+)
 create mode 100644 
meta/recipes-devtools/elfutils/elfutils-0.166/0001-Add-GCC7-Wimplicit-fallthrough-support-fixes.patch
 create mode 100644 
meta/recipes-devtools/elfutils/elfutils-0.166/0001-ar-Fix-GCC7-Wformat-length-issues.patch
 create mode 100644 
meta/recipes-devtools/elfutils/elfutils-0.166/Fix_one_GCC7_warning.patch
 create mode 100644 
meta/recipes-devtools/elfutils/elfutils-0.166/fallthrough.patch

diff --git 
a/meta/recipes-devtools/elfutils/elfutils-0.166/0001-Add-GCC7-Wimplicit-fallthrough-support-fixes.patch
 
b/meta/recipes-devtools/elfutils/elfutils-0.166/0001-Add-GCC7-Wimplicit-fallthrough-support-fixes.patch
new file mode 100644
index 00..a240323f33
--- /dev/null
+++ 
b/meta/recipes-devtools/elfutils/elfutils-0.166/0001-Add-GCC7-Wimplicit-fallthrough-support-fixes.patch
@@ -0,0 +1,318 @@
+From 09949994e76eea3c1230a5c88ffa8fdf588b120f Mon Sep 17 00:00:00 2001
+From: Mark Wielaard 
+Date: Wed, 2 Nov 2016 13:29:26 +0100
+Subject: [PATCH] Add GCC7 -Wimplicit-fallthrough support/fixes.
+
+GCC7 will have a new -Wimplicit-fallthrough warning. It did catch one
+small buglet in elflint option procession. So it seems useful to enable
+to make sure all swatch case fallthroughs are deliberate.
+
+Add configure check to detect whether gcc support -Wimplicit-fallthrough
+and enable it. Add fixes and explicit fallthrough comments where necessary.
+
+Signed-off-by: Mark Wielaard 
+
+Upstream-Status: Backport
+Upstream-Commit: a3cc8182b2ae05290b0eafa74b70746d7befc0e4
+---
+ backends/alpha_retval.c|  4 +---
+ backends/i386_regs.c   |  1 +
+ backends/i386_retval.c |  3 +--
+ backends/linux-core-note.c |  4 ++--
+ backends/ppc_regs.c|  2 +-
+ backends/x86_64_regs.c |  1 +
+ config/eu.am   |  8 +++-
+ configure.ac   | 10 ++
+ libcpu/i386_disasm.c   |  2 +-
+ libdw/cfi.c|  2 ++
+ libdw/encoded-value.h  |  1 +
+ libdwfl/dwfl_report_elf.c  |  2 +-
+ src/addr2line.c|  1 +
+ src/elfcompress.c  |  3 ++-
+ src/elflint.c  |  4 +++-
+ src/objdump.c  |  4 +++-
+ tests/backtrace-data.c |  1 +
+ tests/backtrace.c  |  2 +-
+ 18 files changed, 40 insertions(+), 15 deletions(-)
+
+diff --git a/backends/alpha_retval.c b/backends/alpha_retval.c
+index 53dbfa45..7232b462 100644
+--- a/backends/alpha_retval.c
 b/backends/alpha_retval.c
+@@ -130,9 +130,7 @@ alpha_return_value_location (Dwarf_Die *functypedie, const 
Dwarf_Op **locp)
+   return nloc_intreg;
+ }
+   }
+-
+-  /* Else fall through.  */
+-
++  /* Fallthrough */
+ case DW_TAG_structure_type:
+ case DW_TAG_class_type:
+ case DW_TAG_union_type:
+diff --git a/backends/i386_regs.c b/backends/i386_regs.c
+index fb8ded33..fd963a62 100644
+--- a/backends/i386_regs.c
 b/backends/i386_regs.c
+@@ -92,6 +92,7 @@ i386_register_info (Ebl *ebl __attribute__ ((unused)),
+ case 5:
+ case 8:
+   *type = DW_ATE_address;
++  /* Fallthrough */
+ case 0 ... 3:
+ case 6 ... 7:
+   name[0] = 'e';
+diff --git a/backends/i386_retval.c b/backends/i386_retval.c
+index 9da797d5..4aa646fe 100644
+--- a/backends/i386_retval.c
 b/backends/i386_retval.c
+@@ -122,9 +122,8 @@ i386_return_value_location (Dwarf_Die *functypedie, const 
Dwarf_Op **locp)
+ return nloc_intreg;
+   if (size <= 8)
+ return nloc_intregpair;
+-
+-  /* Else fall through.  */
+   }
++/* Fallthrough */
+ 
+ case DW_TAG_structure_type:
+ case DW_TAG_class_type:
+diff --git a/backends/linux-core-note.c b/backends/linux-core-note.c
+index ff2b226f..321721f3 100644
+--- a/backends/linux-core-note.c
 b/backends/linux-core-note.c
+@@ -219,8 +219,8 @@ EBLHOOK(core_note) (const GElf_Nhdr *nhdr, const char 
*name,
+ case sizeof "CORE":
+   if (memcmp (name, "CORE"

Re: [OE-core] [morty][PATCH] gcc-6.2: backport fix of check for empty string in ubsan.c

2017-06-07 Thread Cody P Schafer 
On Wed, Jun 7, 2017 at 2:46 PM, Cody P Schafer  wrote:
> From: Joshua Lock 
>
> Building gcc-cross-initial with GCC7 on the host fails due to the
> comparison of a pointer to an integer in ubsan_use_new_style_p, which
> is forbidden by ISO C++:

The patch to oe-core master was for gcc 6.3, I've modified it to apply
to gcc 6.2 (which is in morty).

We probably also need to backport the CVE patch, and examine the
6.2..6.3 log to see if there are any other critical patches. Or just
put gcc 6.3 into morty.

This at just gets gcc building for me again.
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [morty][PATCH] gcc-6.2: backport fix of check for empty string in ubsan.c

2017-06-07 Thread Cody P Schafer 
From: Joshua Lock 

Building gcc-cross-initial with GCC7 on the host fails due to the
comparison of a pointer to an integer in ubsan_use_new_style_p, which
is forbidden by ISO C++:

ubsan.c:1474:23: error: ISO C++ forbids comparison between pointer and
integer [-fpermissive]
   || xloc.file == '\0' || xloc.file[0] == '\xff'

Backport the fix from upstream GCC to enable the build with GCC 7

(From OE-Core rev: 7a7fcbab0365b9501c737dbc02715be14dda72a3)

Signed-off-by: Joshua Lock 
Signed-off-by: Richard Purdie 
Signed-off-by: Cody P Schafer 
---
 meta/recipes-devtools/gcc/gcc-6.2.inc  |  5 ++--
 .../gcc/gcc-6.2/ubsan-fix-check-empty-string.patch | 28 ++
 2 files changed, 31 insertions(+), 2 deletions(-)
 create mode 100644 
meta/recipes-devtools/gcc/gcc-6.2/ubsan-fix-check-empty-string.patch

diff --git a/meta/recipes-devtools/gcc/gcc-6.2.inc 
b/meta/recipes-devtools/gcc/gcc-6.2.inc
index b118995e1d..39ae653805 100644
--- a/meta/recipes-devtools/gcc/gcc-6.2.inc
+++ b/meta/recipes-devtools/gcc/gcc-6.2.inc
@@ -80,8 +80,9 @@ SRC_URI = "\

file://0047-libgcc_s-Use-alias-for-__cpu_indicator_init-instead-.patch \
${BACKPORTS} \
 "
-BACKPORTS = ""
-
+BACKPORTS = "\
+   file://ubsan-fix-check-empty-string.patch \
+"
 SRC_URI[md5sum] = "9768625159663b300ae4de2f4745fcc4"
 SRC_URI[sha256sum] = 
"9944589fc722d3e66308c0ce5257788ebd7872982a718aa2516123940671b7c5"
 
diff --git 
a/meta/recipes-devtools/gcc/gcc-6.2/ubsan-fix-check-empty-string.patch 
b/meta/recipes-devtools/gcc/gcc-6.2/ubsan-fix-check-empty-string.patch
new file mode 100644
index 00..c0127198e0
--- /dev/null
+++ b/meta/recipes-devtools/gcc/gcc-6.2/ubsan-fix-check-empty-string.patch
@@ -0,0 +1,28 @@
+From 8db2cf6353c13f2a84cbe49b689654897906c499 Mon Sep 17 00:00:00 2001
+From: kyukhin 
+Date: Sat, 3 Sep 2016 10:57:05 +
+Subject: [PATCH] gcc/  * ubsan.c (ubsan_use_new_style_p): Fix check for empty
+ string.
+
+git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@239971 
138bc75d-0d04-0410-961f-82ee72b054a4
+
+Upstream-Status: Backport
+Signed-off-by: Joshua Lock 
+
+---
+ gcc/ubsan.c   | 2 +-
+ 2 files changed, 5 insertions(+), 1 deletion(-)
+
+Index: gcc-6.3.0/gcc/ubsan.c
+===
+--- gcc-6.3.0.orig/gcc/ubsan.c
 gcc-6.3.0/gcc/ubsan.c
+@@ -1471,7 +1471,7 @@ ubsan_use_new_style_p (location_t loc)
+ 
+   expanded_location xloc = expand_location (loc);
+   if (xloc.file == NULL || strncmp (xloc.file, "\1", 2) == 0
+-  || xloc.file == '\0' || xloc.file[0] == '\xff'
++  || xloc.file[0] == '\0' || xloc.file[0] == '\xff'
+   || xloc.file[1] == '\xff')
+ return false;
+ 
-- 
2.13.0

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

[OE-core] [morty][PATCH] automake: Backport perl 5.22 fix

2017-06-07 Thread Cody P Schafer 
From: Marek Vasut 

Backport 13f00eb4493c "automake: port to Perl 5.22 and later"
from automake upstream to fix build with perl 5.22 .

(From OE-Core rev: 7fa044e799db651d45e4732e2527acfc2bc7cd47)

Signed-off-by: Marek Vasut 
Cc: Ross Burton 
Cc: Richard Purdie 
Signed-off-by: Ross Burton 
Signed-off-by: Cody P Schafer 
---
 ...0001-automake-port-to-Perl-5.22-and-later.patch | 32 ++
 meta/recipes-devtools/automake/automake_1.15.bb|  4 ++-
 2 files changed, 35 insertions(+), 1 deletion(-)
 create mode 100644 
meta/recipes-devtools/automake/automake/0001-automake-port-to-Perl-5.22-and-later.patch

diff --git 
a/meta/recipes-devtools/automake/automake/0001-automake-port-to-Perl-5.22-and-later.patch
 
b/meta/recipes-devtools/automake/automake/0001-automake-port-to-Perl-5.22-and-later.patch
new file mode 100644
index 00..0e6895fb4b
--- /dev/null
+++ 
b/meta/recipes-devtools/automake/automake/0001-automake-port-to-Perl-5.22-and-later.patch
@@ -0,0 +1,32 @@
+From 13f00eb4493c217269b76614759e452d8302955e Mon Sep 17 00:00:00 2001
+From: Paul Eggert 
+Date: Thu, 31 Mar 2016 16:35:29 -0700
+Subject: [PATCH] automake: port to Perl 5.22 and later
+
+Without this change, Perl 5.22 complains "Unescaped left brace in
+regex is deprecated" and this is planned to become a hard error in
+Perl 5.26.  See:
+http://search.cpan.org/dist/perl-5.22.0/pod/perldelta.pod#A_literal_%22{%22_should_now_be_escaped_in_a_pattern
+* bin/automake.in (substitute_ac_subst_variables): Escape left brace.
+
+Upstream-Status: Backport [13f00eb4493c217269b76614759e452d8302955e]
+---
+ bin/automake.in | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/bin/automake.in b/bin/automake.in
+index a3a0aa318..2c8f31e14 100644
+--- a/bin/automake.in
 b/bin/automake.in
+@@ -3878,7 +3878,7 @@ sub substitute_ac_subst_variables_worker
+ sub substitute_ac_subst_variables
+ {
+   my ($text) = @_;
+-  $text =~ s/\${([^ \t=:+{}]+)}/substitute_ac_subst_variables_worker ($1)/ge;
++  $text =~ s/\$[{]([^ \t=:+{}]+)}/substitute_ac_subst_variables_worker 
($1)/ge;
+   return $text;
+ }
+ 
+-- 
+2.11.0
+
diff --git a/meta/recipes-devtools/automake/automake_1.15.bb 
b/meta/recipes-devtools/automake/automake_1.15.bb
index a3c72fd334..61ae3ba3e3 100644
--- a/meta/recipes-devtools/automake/automake_1.15.bb
+++ b/meta/recipes-devtools/automake/automake_1.15.bb
@@ -21,7 +21,9 @@ RDEPENDS_${PN}_class-native = "autoconf-native 
hostperl-runtime-native"
 SRC_URI += " file://python-libdir.patch \
 file://buildtest.patch \
 file://performance.patch \
-file://new_rt_path_for_test-driver.patch"
+file://new_rt_path_for_test-driver.patch \
+file://0001-automake-port-to-Perl-5.22-and-later.patch \
+"
 
 SRC_URI[md5sum] = "716946a105ca228ab545fc37a70df3a3"
 SRC_URI[sha256sum] = 
"7946e945a96e28152ba5a6beb0625ca715c6e32ac55f2e353ef54def0c8ed924"
-- 
2.13.0

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

[OE-core] [PATCH v2] runqemu-export-rootfs: don't change RPC ports

2017-06-06 Thread Cody P Schafer 
RPC ports (also known as rpc program numbers) are values:

 - given to rpcbind (aka portmapper) to allow nfsv3 clients that don't
   know the tcp/udp port number of nfsd and mountd to look it up the
   tcp/udp port number, and to

 - allow a single transport (ie: tcp/udp port) to provide multiple
   sunrpc services.

OE has carried patches to nfsutils & linux for some time to support the
mountprog & nfsprog options.

In the case of runqemu-export-rootfs, we don't need to use custom rpc
program numbers because runqemu-export-rootfs tells unfsd not to
register with the portmapper, and unfsd runs the nfs and mount rpc
services on tcp/udp ports unfsd binds itself (iow: the tcp/udp ports are
not shared in the sunrpc sense).

Linux's nfs client does not query rpcbind when tcp/udp port numbers are
specified (in net/sunrpc/clnt.c, call_bind checks for the tcp/udp port
with xprt_bound() and skips the call to rpcbind if xprtsock.c's
xs_setup_udp() or xs_setup_tcp() has found a non-zero tcp/udp port).

The program numbers _are_ sent over the mount & nfs protocol (really,
over sunrpc), and checked to match at both ends. As a result, even when
rpcbind is unused, using different program numbers in unfsd vs linux
nfs client causes mounts to fail (and nfsroot mounts to timeout).

The result is that specifying custom program numbers in
runqemu-export-rootfs doesn't solve any conflicts, it simply requires
that users of runqemu-export-rootfs carry a kernel patch & adds 2 extra
parameters to the kernel command line unnecessarily.

Change runqemu-export-rootfs to use the default program numbers.

For now, I have not dropped the custom program number patches to linux,
nfs-utils, and unfsd just in case someone is using them in a
non-runqemu-export-rootfs context.

CC: Bruce Ashfield 
CC: Mark Hatle 
Signed-off-by: Cody P Schafer 
---
v2: add a much better commit message to clarify some confusion
---
 scripts/runqemu-export-rootfs | 8 ++--
 1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/scripts/runqemu-export-rootfs b/scripts/runqemu-export-rootfs
index c7992d8223..70cdcdbb13 100755
--- a/scripts/runqemu-export-rootfs
+++ b/scripts/runqemu-export-rootfs
@@ -77,10 +77,6 @@ if [ ! -d "$PSEUDO_LOCALSTATEDIR" ]; then
exit 1  
 fi
 
-# rpc.mountd RPC port
-MOUNTD_RPCPORT=${MOUNTD_RPCPORT:=$[ 2 + $NFS_INSTANCE ]}
-# rpc.nfsd RPC port
-NFSD_RPCPORT=${NFSD_RPCPORT:=$[ 1 + $NFS_INSTANCE ]}
 # NFS server port number
 NFSD_PORT=${NFSD_PORT:=$[ 3049 + 2 * $NFS_INSTANCE ]}
 # mountd port number
@@ -88,7 +84,7 @@ MOUNTD_PORT=${MOUNTD_PORT:=$[ 3048 + 2 * $NFS_INSTANCE ]}
 
 ## For debugging you would additionally add
 ## --debug all
-UNFSD_OPTS="-p -N -i $NFSPID -e $EXPORTS -x $NFSD_RPCPORT -n $NFSD_PORT -y 
$MOUNTD_RPCPORT -m $MOUNTD_PORT"
+UNFSD_OPTS="-p -N -i $NFSPID -e $EXPORTS -n $NFSD_PORT -m $MOUNTD_PORT"
 
 # See how we were called.
 case "$1" in
@@ -130,7 +126,7 @@ case "$1" in
fi
echo " "
echo "On your target please remember to add the following options for 
NFS"
-   echo 
"nfsroot=IP_ADDRESS:$NFS_EXPORT_DIR,nfsvers=3,port=$NFSD_PORT,mountprog=$MOUNTD_RPCPORT,nfsprog=$NFSD_RPCPORT,udp,mountport=$MOUNTD_PORT"
+   echo 
"nfsroot=IP_ADDRESS:$NFS_EXPORT_DIR,nfsvers=3,port=$NFSD_PORT,udp,mountport=$MOUNTD_PORT"
;;
   stop)
if [ -f "$NFSPID" ]; then
-- 
2.13.0

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

Re: [OE-core] [PATCH] runqemu-export-rootfs: don't change RPC ports

2017-06-01 Thread Cody P Schafer 
On Thu, Jun 1, 2017 at 1:02 PM, Mark Hatle  wrote:

>
> The rpcbind runs on a privileged port (usually).  So either you have to 
> 're-use'
> the system wide on or run your own.  On many environments, with a system wide
> one, you will clash if someone else is offering the same services.  So you are
> forced to run your own and/or register then with a different set of port 
> numbers.
>
> This is absolutely needed in a multi-user or 'locked system' configuration 
> where
> the user does not have permission to run these types of things.

unfsd does not include rpcbind, it optionally uses the system's rpcbind.

In the runqemu-export-rootfs case, unfsd does not use any rpcbind at all.

Still not seeing anything that would require runqemu-export-rootfs to
use custom rpc program numbers.
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] runqemu-export-rootfs: don't change RPC ports

2017-05-31 Thread Cody P Schafer 
> RPC Ports are just the bindings into rpcbind.   The tcp/udp ports are the ones
> that typically conflict and why this was all done to begin with.

Ok, then it doesn't sound like that is a conflict or a "privileged
ports" issue, and it is safe to drop the custom rpc program numbers
("RPC Ports") from `unfsd`s arguments & the kernel parameters.

As I've noted, runqemu-export-rootfs does not register with rpcbind
(we pass the `-p` flag to `unfsd`).

Or is there something else system-wide which is keeping a list of rpc
program numbers?
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] runqemu-export-rootfs: don't change RPC ports

2017-05-31 Thread Cody P Schafer 
> Non-root user can't create privileged ports.

I presume you're speaking about tcp/udp ports here? (having the
program numbers referred to as "RPC ports" in some contexts confuses
things). Or does unfsd tell the kernel about it's rpc program numbers
(called "RPC ports" in the script) somehow & restrict them too?

If it is the first, it isn't clear why that is relevant: I'm not
trying to have unfsd use privileged tcp/udp ports (it's already using
non-privlidged tcp/udp ports). I'm trying to drop the custom rpc
program numbers (which are referred to as "RPC Ports" in the script).
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] runqemu-export-rootfs: don't change RPC ports

2017-05-31 Thread Cody P Schafer 
> There's a patch that we've had for years to allow alternate RPC ports
> to work with userspace NFS and co-exist with existing NFS servers.

Ah, I see (I should have checked that sooner). "NFS: allow nfs root
mount to use alternate rpc ports". I can likely just pull that into my
kernel and have things work fine without changes to
runqemu-export-rootfs.

> This would have an impact on that functionality, so if we do need to
> change those ports, the existing ones should be maintained with some
> sort of option to change the nfsroot line.

Yep, that makes sense.

That said: it isn't completely clear to me that a seperate rpc program
number (aka RPC port) is needed to avoid conflicts between 2 nfs
instances in this case:

 - we don't have unfsd register with rpcbind (-p option), so the rpc
program numbers won't conflict there.
 - using nfsroot implicitly adds the 'nolock' option, so there isn't a
conflict there
 - I did my tests with the nfs kernel server running. There wasn't an
immdiate issue observed with mounting and accessing both a kernel
provided export & a unfsd provided export (using
runqemu-export-rootfs) at the same time.

Still, I'm not too familiar with all of the ins and outs of nfs. Is
there somewhere I've overlooked where the program numbers could
conflict?
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] runqemu-export-rootfs: don't change RPC ports

2017-05-30 Thread Cody P Schafer 
> The result of this is that trying to mount filesystems exported by
> runqemu-export-rootfs in modern kernels (at least in 4.2 and later, and
> probably more like 2.6.20 and later) doesn't actually work.

To clarify, when using nfsroot with the current kernel & unfsd
options, my boot stops, waits for the nfs root to appear, and then
times out. When trying to mount normally (ie: via `mount -t nfs` of a
very recent vintage in arch-linux), I get immediate "protocol family
not supported" errors.

With this change, both mount methods (nfsroot with new kernel options
and normally mount) work without issue.

> I'm honestly not sure how anyone was using this for nfsroot support.
> Maybe an initramfs with a version of nfs-utils that could handle the
> mountprog/nfsprog option was in use? Not sure.

Or is there some yocto kernel patch to enable support for it? I'm
running a custom kernel.
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] runqemu-export-rootfs: don't change RPC ports

2017-05-30 Thread Cody P Schafer 
The mountprog & nfsprog options given are not supported in the linux
kernel, and the only references I can find to them are in the nfs-utils
source, which notes:

  "mountprog" is supported only by the legacy mount command.  The
  kernel mount client does not support this option.

(and similar for nfsprog).

The kernel (which is what parses `nfsroot=` when using nfsroot)
has no understanding of nfsprog or mountprog.

The result of this is that trying to mount filesystems exported by
runqemu-export-rootfs in modern kernels (at least in 4.2 and later, and
probably more like 2.6.20 and later) doesn't actually work.

I'm honestly not sure how anyone was using this for nfsroot support.
Maybe an initramfs with a version of nfs-utils that could handle the
mountprog/nfsprog option was in use? Not sure.

Signed-off-by: Cody P Schafer 
---
 scripts/runqemu-export-rootfs | 8 ++--
 1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/scripts/runqemu-export-rootfs b/scripts/runqemu-export-rootfs
index c7992d8223..70cdcdbb13 100755
--- a/scripts/runqemu-export-rootfs
+++ b/scripts/runqemu-export-rootfs
@@ -77,10 +77,6 @@ if [ ! -d "$PSEUDO_LOCALSTATEDIR" ]; then
exit 1  
 fi
 
-# rpc.mountd RPC port
-MOUNTD_RPCPORT=${MOUNTD_RPCPORT:=$[ 2 + $NFS_INSTANCE ]}
-# rpc.nfsd RPC port
-NFSD_RPCPORT=${NFSD_RPCPORT:=$[ 1 + $NFS_INSTANCE ]}
 # NFS server port number
 NFSD_PORT=${NFSD_PORT:=$[ 3049 + 2 * $NFS_INSTANCE ]}
 # mountd port number
@@ -88,7 +84,7 @@ MOUNTD_PORT=${MOUNTD_PORT:=$[ 3048 + 2 * $NFS_INSTANCE ]}
 
 ## For debugging you would additionally add
 ## --debug all
-UNFSD_OPTS="-p -N -i $NFSPID -e $EXPORTS -x $NFSD_RPCPORT -n $NFSD_PORT -y 
$MOUNTD_RPCPORT -m $MOUNTD_PORT"
+UNFSD_OPTS="-p -N -i $NFSPID -e $EXPORTS -n $NFSD_PORT -m $MOUNTD_PORT"
 
 # See how we were called.
 case "$1" in
@@ -130,7 +126,7 @@ case "$1" in
fi
echo " "
echo "On your target please remember to add the following options for 
NFS"
-   echo 
"nfsroot=IP_ADDRESS:$NFS_EXPORT_DIR,nfsvers=3,port=$NFSD_PORT,mountprog=$MOUNTD_RPCPORT,nfsprog=$NFSD_RPCPORT,udp,mountport=$MOUNTD_PORT"
+   echo 
"nfsroot=IP_ADDRESS:$NFS_EXPORT_DIR,nfsvers=3,port=$NFSD_PORT,udp,mountport=$MOUNTD_PORT"
;;
   stop)
if [ -f "$NFSPID" ]; then
-- 
2.13.0

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

[OE-core] [PATCH v2 2/2] cmake.bbclass: use `cmake --build` to build & install

2017-05-04 Thread Cody P Schafer 
Rather than presuming `make` is the generator, use cmake's generic
`cmake --build` feature (which knows to call the appropriate generator).

Both DESTDIR and VERBOSE still behave as intended when used as
environment variables instead of make variable-arguments.

As cmake-based builds don't do any configuration with `make`
invocations, we only pass `PARALLEL_MAKE{,INST}` (via a
EXTRA_OECMAKE_BUILD variable) to the underlying build tool. Make &
ninja support the same `-j N` option (and a few others), so this does
happen to work for both.

This makes it more straight forward for others to select other cmake
generators (many folks have been reaching for `ninja` lately).

CC: Andre McCurdy 
Signed-off-by: Cody P Schafer 
---
 meta/classes/cmake.bbclass | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/meta/classes/cmake.bbclass b/meta/classes/cmake.bbclass
index 8b5f18d8e0..ac2c1519b0 100644
--- a/meta/classes/cmake.bbclass
+++ b/meta/classes/cmake.bbclass
@@ -31,6 +31,9 @@ OECMAKE_FIND_ROOT_PATH_MODE_PROGRAM_class-native = "BOTH"
 
 EXTRA_OECMAKE_append = " ${PACKAGECONFIG_CONFARGS}"
 
+EXTRA_OECMAKE_BUILD_prepend_task-compile = "${PARALLEL_MAKE} "
+EXTRA_OECMAKE_BUILD_prepend_task-install = "${PARALLEL_MAKEINST} "
+
 # CMake expects target architectures in the format of uname(2),
 # which do not always match TARGET_ARCH, so all the necessary
 # conversions should happen here.
@@ -135,11 +138,13 @@ cmake_do_configure() {
 
 do_compile[progress] = "percent"
 cmake_do_compile()  {
-   base_do_compile VERBOSE=1
+   bbnote VERBOSE=1 cmake --build '${B}' -- ${EXTRA_OECMAKE_BUILD}
+   VERBOSE=1 cmake --build '${B}' -- ${EXTRA_OECMAKE_BUILD}
 }
 
 cmake_do_install() {
-   oe_runmake 'DESTDIR=${D}' install
+   bbnote DESTDIR='${D}' cmake --build '${B}' --target install -- 
${EXTRA_OECMAKE_BUILD}
+   DESTDIR='${D}' cmake --build '${B}' --target install -- 
${EXTRA_OECMAKE_BUILD}
 }
 
 EXPORT_FUNCTIONS do_configure do_compile do_install do_generate_toolchain_file
-- 
2.12.2

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

[OE-core] [PATCH v2 1/2] cmake.bbclass: remove unneded cd ${B}

2017-05-04 Thread Cody P Schafer 
The default dir for do_compile & do_configure is already ${B}, no need
to cd (other than broken appends)

CC: Andre McCurdy 
Signed-off-by: Cody P Schafer 
---
 meta/classes/cmake.bbclass | 2 --
 1 file changed, 2 deletions(-)

diff --git a/meta/classes/cmake.bbclass b/meta/classes/cmake.bbclass
index 12df617ad8..8b5f18d8e0 100644
--- a/meta/classes/cmake.bbclass
+++ b/meta/classes/cmake.bbclass
@@ -135,12 +135,10 @@ cmake_do_configure() {
 
 do_compile[progress] = "percent"
 cmake_do_compile()  {
-   cd ${B}
base_do_compile VERBOSE=1
 }
 
 cmake_do_install() {
-   cd ${B}
oe_runmake 'DESTDIR=${D}' install
 }
 
-- 
2.12.2

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

[OE-core] [PATCH] binutils: package libbfd seperately

2017-05-02 Thread Cody P Schafer 
Some tools (my issue was with 'perf') only need the libbfd component of
binutils, so we can save space in images by splitting it out.

Previously, instead of `perf` pulling in `libbfd-VERSION.so`, it pulled
in all the libraries and binaries from binutils.

Signed-off-by: Cody P Schafer 
---
 meta/recipes-devtools/binutils/binutils.inc | 4 
 1 file changed, 4 insertions(+)

diff --git a/meta/recipes-devtools/binutils/binutils.inc 
b/meta/recipes-devtools/binutils/binutils.inc
index 7efe13fdf6..068dce8ee0 100644
--- a/meta/recipes-devtools/binutils/binutils.inc
+++ b/meta/recipes-devtools/binutils/binutils.inc
@@ -21,6 +21,10 @@ EXTRANATIVEPATH_append_class-target = " chrpath-native"
 
 inherit autotools gettext multilib_header texinfo
 
+# Split out libbfd-*.so so including perf doesn't include extra stuff
+PACKAGE_BEFORE_PN += "libbfd"
+FILES_libbfd = "${libdir}/libbfd-*.so"
+
 FILES_${PN} = " \
${bindir}/${TARGET_PREFIX}* \
${libdir}/lib*-*.so \
-- 
2.12.2

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

Re: [OE-core] [PATCH] cmake.bbclass: use `cmake --build` to build & install

2017-05-02 Thread Cody P Schafer 
On Tue, May 2, 2017 at 12:49 PM, Andre McCurdy  wrote:
> On Tue, May 2, 2017 at 8:49 AM, Cody P Schafer  wrote:
>>>>  do_compile[progress] = "percent"
>>>>  cmake_do_compile()  {
>>>> -   cd ${B}
>>>
>>> Removing the redundant "cd ${B}" should perhaps be a separate commit?
>>
>> I'm not really seeing that as useful, change right now can be viewed
>> as "moves the ${B} from being in `cd` to being part of the command
>> line for `cmake --build`". Is fairly straight forward because cmake
>> requires a path be specified (where `make` makes it optional).
>
> If ${B} is the default directory for both these tasks then "cd ${B}"
> is redundant and can be removed. If it is not the default directory,
> then removing it will potentially break do_compile_append() and
> do_install_append() functions which rely on running in ${B}. That
> logic doesn't depend on whether or not "cmake --build" takes care of
> changing directory on it's own, so if "cd ${B}" is redundant, then
> removing it should be standalone commit.

meta/classes/base.bbclass
307:do_configure[dirs] = "${B}"
326:do_compile[dirs] = "${B}"

${B} is the default dir for do_compile & do_configure.

Are we concerned about prepend scripts changing the directory to
something not-${B} & appends implicitly relying on ${B} being the
directory?

It seems that prepends/appends should avoid changing directories &/or
avoid depending on a specific directory. Many (but not all) of the
appends I've seen are pretty explicitly about the dirs they need
(Using ${B}, ${S}, and ${WORKDIR} as needed instead of assuming the
dir). Is there a policy on what the right thing to do is w.r.t. cwd
changes within tasks & specifically within appends/prepends to tasks?
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] cmake.bbclass: use `cmake --build` to build & install

2017-05-02 Thread Cody P Schafer 
>>  do_compile[progress] = "percent"
>>  cmake_do_compile()  {
>> -   cd ${B}
>
> Removing the redundant "cd ${B}" should perhaps be a separate commit?

I'm not really seeing that as useful, change right now can be viewed
as "moves the ${B} from being in `cd` to being part of the command
line for `cmake --build`". Is fairly straight forward because cmake
requires a path be specified (where `make` makes it optional).

>
>> -   base_do_compile VERBOSE=1
>> +   VERBOSE=1 cmake --build '${B}'
>
> This looks like it will cause parallel make and EXTRA_OEMAKE options
> to be ignored?

That is a good point. I don't think EXTRA_OEMAKE should matter here
too much as configuration for cmake-based builds all is read at
configure time, but the ${PARALLEL_MAKE} flag is definitely an issue.

Doing this could work:

VERBOSE=1 cmake --build '${B}' -- ${EXTRA_OEMAKE}

(And similar for install)

And for the case of `-jN` like flags, make & ninja happen to be
compatible (they share a few other flags, like `-l` and `-n`.

Another alternative is passing ${PARALLEL_MAKE} (and
${PARALLEL_MAKEINST}) instead of directly using ${EXTRA_OEMAKE}.

Also: I took a look at what else `run_oemake` is doing, and it
contains some output printing (`bbnote`s the make command & `die`s on
make failure), which could be added directly around the `cmake
--build` invocations instead.
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] cmake.bbclass: use `cmake --build` to build & install

2017-05-01 Thread Cody P Schafer 
Rather than presuming `make` is the generator, use cmake's generic
`cmake --build` feature (which knows to call the appropriate generator).

Both DESTDIR and VERBOSE still behave as intended when used as
environment variables instead of make variable-arguments.

This makes it more straight forward for others to select other cmake
generators (many folks have been reaching for `ninja` lately).

Signed-off-by: Cody P Schafer 
---
 meta/classes/cmake.bbclass | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/meta/classes/cmake.bbclass b/meta/classes/cmake.bbclass
index 12df617ad8..05ec50d385 100644
--- a/meta/classes/cmake.bbclass
+++ b/meta/classes/cmake.bbclass
@@ -135,13 +135,11 @@ cmake_do_configure() {
 
 do_compile[progress] = "percent"
 cmake_do_compile()  {
-   cd ${B}
-   base_do_compile VERBOSE=1
+   VERBOSE=1 cmake --build '${B}'
 }
 
 cmake_do_install() {
-   cd ${B}
-   oe_runmake 'DESTDIR=${D}' install
+   DESTDIR='${D}' cmake --build '${B}' --target install
 }
 
 EXPORT_FUNCTIONS do_configure do_compile do_install do_generate_toolchain_file
-- 
2.12.2

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

[OE-core] [PATCH] cmake: in SDK use OE env var to set default toolchain

2017-05-01 Thread Cody P Schafer 
Patch the location in cmake where the toolchain file is loaded
to use the (new) OE_CMAKE_TOOLCHAIN_FILE variable to select a default
toolchain if no toolchain has been specified. The cmake alias is
removed.

The alternatives:

 - shell alias fails when cmake is called indirectly (ex: a makefile
   managing several projects which calls cmake for some of them)
   because aliases are not inherited

 - wrapper script that unconditionally adds "-D..." breaks cmake's
   build tests and many other things as it causes cmake to believe it
   should be configuring things when it should not be. For example,
   `cmake -DCMAKE_TOOLCHAIN_FILE=... --build .` does not work (note
   that this also breaks people directly using `cmake --build .` with
   the current alias).

Signed-off-by: Cody P Schafer 
---
 ...ineSystem-use-oe-environment-vars-to-load.patch | 45 ++
 .../cmake/cmake/environment.d-cmake.sh |  2 +-
 meta/recipes-devtools/cmake/cmake_3.7.2.bb |  4 +-
 3 files changed, 49 insertions(+), 2 deletions(-)
 create mode 100644 
meta/recipes-devtools/cmake/cmake/0001-CMakeDetermineSystem-use-oe-environment-vars-to-load.patch

diff --git 
a/meta/recipes-devtools/cmake/cmake/0001-CMakeDetermineSystem-use-oe-environment-vars-to-load.patch
 
b/meta/recipes-devtools/cmake/cmake/0001-CMakeDetermineSystem-use-oe-environment-vars-to-load.patch
new file mode 100644
index 00..a2332879cf
--- /dev/null
+++ 
b/meta/recipes-devtools/cmake/cmake/0001-CMakeDetermineSystem-use-oe-environment-vars-to-load.patch
@@ -0,0 +1,45 @@
+From a42cfebcd6c684cccf8ad33e5bd5130f7cdba135 Mon Sep 17 00:00:00 2001
+From: Cody P Schafer 
+Date: Thu, 27 Apr 2017 11:35:05 -0400
+Subject: [PATCH] CMakeDetermineSystem: use oe environment vars to load default
+ toolchain file in sdk
+
+Passing the toolchain by:
+
+ - shell aliases does not work if cmake is called by a script
+ - unconditionally by a wrapper script causes cmake to believe it is
+   configuring things when it is not (for example, `cmake --build` breaks).
+
+The OE_CMAKE_TOOLCHAIN_FILE variable is only used as a default if no
+toolchain is explicitly specified.
+
+Setting the CMAKE_TOOLCHAIN_FILE cmake variable is marked as cached
+because '-D' options are cache entries themselves.
+
+Upstream-Status: Inappropriate [oe-core specific]
+Signed-off-by: Cody P Schafer 
+---
+ Modules/CMakeDetermineSystem.cmake | 7 +++
+ 1 file changed, 7 insertions(+)
+
+diff --git a/Modules/CMakeDetermineSystem.cmake 
b/Modules/CMakeDetermineSystem.cmake
+index f34ec5d61..bcac3ef16 100644
+--- a/Modules/CMakeDetermineSystem.cmake
 b/Modules/CMakeDetermineSystem.cmake
+@@ -74,6 +74,13 @@ else()
+   endif()
+ endif()
+ 
++if(NOT DEFINED CMAKE_TOOLCHAIN_FILE)
++  if(DEFINED ENV{OE_CMAKE_TOOLCHAIN_FILE})
++set(CMAKE_TOOLCHAIN_FILE "$ENV{OE_CMAKE_TOOLCHAIN_FILE}" CACHE FILEPATH 
"toolchain file")
++message(STATUS "Toolchain file defaulted to '${CMAKE_TOOLCHAIN_FILE}'")
++  endif()
++endif()
++
+ # if a toolchain file is used, the user wants to cross compile.
+ # in this case read the toolchain file and keep the CMAKE_HOST_SYSTEM_*
+ # variables around so they can be used in CMakeLists.txt.
+-- 
+2.12.2
+
diff --git a/meta/recipes-devtools/cmake/cmake/environment.d-cmake.sh 
b/meta/recipes-devtools/cmake/cmake/environment.d-cmake.sh
index 0eb56b66fa..64b6cf3c6a 100644
--- a/meta/recipes-devtools/cmake/cmake/environment.d-cmake.sh
+++ b/meta/recipes-devtools/cmake/cmake/environment.d-cmake.sh
@@ -1 +1 @@
-alias cmake="cmake 
-DCMAKE_TOOLCHAIN_FILE=$OECORE_NATIVE_SYSROOT/usr/share/cmake/OEToolchainConfig.cmake"
+export 
OE_CMAKE_TOOLCHAIN_FILE="$OECORE_NATIVE_SYSROOT/usr/share/cmake/OEToolchainConfig.cmake"
diff --git a/meta/recipes-devtools/cmake/cmake_3.7.2.bb 
b/meta/recipes-devtools/cmake/cmake_3.7.2.bb
index f566a48cfb..1cb99869e6 100644
--- a/meta/recipes-devtools/cmake/cmake_3.7.2.bb
+++ b/meta/recipes-devtools/cmake/cmake_3.7.2.bb
@@ -6,7 +6,9 @@ DEPENDS += "curl expat zlib libarchive xz ncurses bzip2"
 
 SRC_URI_append_class-nativesdk = " \
 file://OEToolchainConfig.cmake \
-file://environment.d-cmake.sh"
+file://environment.d-cmake.sh \
+file://0001-CMakeDetermineSystem-use-oe-environment-vars-to-load.patch \
+"
 
 # Strip ${prefix} from ${docdir}, set result into docdir_stripped
 python () {
-- 
2.12.2

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

[OE-core] [morty][PATCH] gdb-cross-canadian: Depend on nativesdk-python3-importlib

2017-02-07 Thread Cody P Schafer 
From: George McCollister 

Add missing dependency on nativesdk-python3-importlib so the imp Python
module is installed.

Before this patch, running gdb from the sdk would give the following
error:

Python Exception  No module named 'imp':

Signed-off-by: George McCollister 
Signed-off-by: Ross Burton 

(From OE-Core rev: ad00a31fbe93e073a2d83616efcd08c5a7ef37c9)

Signed-off-by: Cody P Schafer 
---
 meta/recipes-devtools/gdb/gdb-cross-canadian.inc | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-devtools/gdb/gdb-cross-canadian.inc 
b/meta/recipes-devtools/gdb/gdb-cross-canadian.inc
index e53081d0c0..3ff1989538 100644
--- a/meta/recipes-devtools/gdb/gdb-cross-canadian.inc
+++ b/meta/recipes-devtools/gdb/gdb-cross-canadian.inc
@@ -14,7 +14,8 @@ GDBPROPREFIX = "--program-prefix='${TARGET_PREFIX}'"
 PACKAGECONFIG ??= "python readline"
 PACKAGECONFIG[python] = 
"--with-python=${WORKDIR}/python,--without-python,nativesdk-python3, \
  nativesdk-python3-core nativesdk-python3-lang 
nativesdk-python3-re \
- nativesdk-python3-codecs nativesdk-python3-netclient"
+ nativesdk-python3-codecs nativesdk-python3-netclient \
+ nativesdk-python3-importlib"
 PACKAGECONFIG[readline] = 
"--with-system-readline,--without-system-readline,nativesdk-readline"
 
 SSTATE_DUPWHITELIST += "${STAGING_DATADIR}/gdb"
-- 
2.11.0

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

[OE-core] [PATCH] cantarell-fonts: add inherit pkgconfig to get pkgconfig dependency

2016-11-18 Thread Cody P Schafer 
Without this, do_configure can fail with:

| ../git/configure: line 2381: syntax error near unexpected token `0.19'
| ../git/configure: line 2381: `PKG_PROG_PKG_CONFIG(0.19)'

If pkgconfig-native happens to be added to the sysroot too late.

Signed-off-by: Cody P Schafer 
---
 meta/recipes-graphics/cantarell-fonts/cantarell-fonts_git.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-graphics/cantarell-fonts/cantarell-fonts_git.bb 
b/meta/recipes-graphics/cantarell-fonts/cantarell-fonts_git.bb
index e3e4cde..c71ab11 100644
--- a/meta/recipes-graphics/cantarell-fonts/cantarell-fonts_git.bb
+++ b/meta/recipes-graphics/cantarell-fonts/cantarell-fonts_git.bb
@@ -18,7 +18,7 @@ UPSTREAM_CHECK_GITTAGREGEX = 
"(?P(?!0\.13)(?!0\.10\.1)\d+\.\d+(\.\d+)+)"
 
 S = "${WORKDIR}/git"
 
-inherit autotools allarch fontcache
+inherit autotools allarch fontcache pkgconfig
 
 PACKAGECONFIG ??= ""
 PACKAGECONFIG[fontforge] = 
"--enable-source-rebuild=yes,--enable-source-rebuild=no,fontforge-native"
-- 
2.10.2

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

Re: [OE-core] [PATCH] cmake: supply CMAKE_AR in toolchain file

2014-12-02 Thread Cody P Schafer 
I tried the bare set(CMAKE_AR ...) first, but found it was being
ignored. A bit of googling found:
http://www.cmake.org/Bug/view.php?id=13038 Which contains the solution
I've used here.

On Wed, Nov 12, 2014 at 11:08 AM, Burton, Ross  wrote:
>
> On 12 November 2014 01:30, Cody P Schafer  wrote:
>>
>> +set( CMAKE_AR ${OECMAKE_AR} CACHE FILEPATH "Archiver" )
>
>
> Curious - why does this line have CACHE FILEPATH "Archiver" when e.g.
> CMAKE_C_COMPILER doesn't?  Should one or other other be fixed?
>
> Ross
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] cmake: supply CMAKE_AR in toolchain file

2014-11-11 Thread Cody P Schafer 
---
 meta/classes/cmake.bbclass | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/meta/classes/cmake.bbclass b/meta/classes/cmake.bbclass
index 10f8f98..3549c38 100644
--- a/meta/classes/cmake.bbclass
+++ b/meta/classes/cmake.bbclass
@@ -13,6 +13,7 @@ inherit autotools
 # C/C++ Compiler (without cpu arch/tune arguments)
 OECMAKE_C_COMPILER ?= "`echo ${CC} | sed 's/^\([^ ]*\).*/\1/'`"
 OECMAKE_CXX_COMPILER ?= "`echo ${CXX} | sed 's/^\([^ ]*\).*/\1/'`"
+OECMAKE_AR ?= "${AR}"
 
 # Compiler flags
 OECMAKE_C_FLAGS ?= "${HOST_CC_ARCH} ${TOOLCHAIN_OPTIONS} ${CFLAGS}"
@@ -35,6 +36,7 @@ set( CMAKE_SYSTEM_PROCESSOR ${TARGET_ARCH} )
 set( CMAKE_C_COMPILER ${OECMAKE_C_COMPILER} )
 set( CMAKE_CXX_COMPILER ${OECMAKE_CXX_COMPILER} )
 set( CMAKE_ASM_COMPILER ${OECMAKE_C_COMPILER} )
+set( CMAKE_AR ${OECMAKE_AR} CACHE FILEPATH "Archiver" )
 set( CMAKE_C_FLAGS "${OECMAKE_C_FLAGS}" CACHE STRING "CFLAGS" )
 set( CMAKE_CXX_FLAGS "${OECMAKE_CXX_FLAGS}" CACHE STRING "CXXFLAGS" )
 set( CMAKE_ASM_FLAGS "${OECMAKE_C_FLAGS}" CACHE STRING "ASM FLAGS" )
-- 
2.1.3

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

[OE-core] [PATCH] Avoid crashing if getgrnam() cannont find a group by the given name

2014-10-25 Thread Cody P Schafer 
Without this, we get (on systems without a 'mail' group):

ERROR: Error executing a python function in 
/home/x/g/poky/meta/recipes-kernel/linux-libc-headers/linux-libc-headers_3.16.bb:

The stack trace of python calls that resulted in this exception/failure 
was:
File: 'fixup_perms', lineno: 231, function: 
 0227:each_file = os.path.join(root, f)
 0228:fix_perms(each_file, 
fs_perms_table[dir].fmode, fs_perms_table[dir].fuid, fs_perms_table[dir].fgid, 
dir)
 0229:
 0230:
 *** 0231:fixup_perms(d)
 0232:
File: 'fixup_perms', lineno: 173, function: fixup_perms
 0169:if len(lsplit) != 8 and not (len(lsplit) == 3 
and lsplit[1].lower() == "link"):
 0170:msg = "Fixup perms: %s invalid line: %s" 
% (conf, line)
 0171:package_qa_handle_error("perm-line", msg, 
d)
 0172:continue
 *** 0173:entry = fs_perms_entry(d.expand(line))
 0174:if entry and entry.path:
 0175:fs_perms_table[entry.path] = entry
 0176:f.close()
 0177:
File: 'fixup_perms', lineno: 32, function: __init__
  File "fixup_perms", line 32, in __init__

File: 'fixup_perms', lineno: 44, function: _setdir
  File "fixup_perms", line 44, in _setdir

File: 'fixup_perms', lineno: 75, function: _procgid
  File "fixup_perms", line 75, in _procgid

Exception: KeyError: 'getgrnam(): name not found: mail'

ERROR: Function failed: fixup_perms
ERROR: Logfile of failure stored in: 
/home/x/obj/y/tmp/work/i586-poky-linux/linux-libc-headers/3.16-r0/temp/log.do_package.15841
ERROR: Task 400 
(/home/x/g/poky/meta/recipes-kernel/linux-libc-headers/linux-libc-headers_3.16.bb,
 do_package) failed with exit code '1'

Signed-off-by: Cody P Schafer 
---
 meta/classes/package.bbclass | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/meta/classes/package.bbclass b/meta/classes/package.bbclass
index 2aec3e6..d7c970b 100644
--- a/meta/classes/package.bbclass
+++ b/meta/classes/package.bbclass
@@ -568,7 +568,10 @@ python fixup_perms () {
 elif gid.isdigit():
 return int(gid)
 else:
-return grp.getgrnam(gid).gr_gid
+try:
+return grp.getgrnam(gid).gr_gid
+except Exception:
+   return -1
 
 # Use for debugging the entries
 def __str__(self):
-- 
2.0.4

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