Re: [OE-core] [PATCH] populate_sdk_base: repeat to tar archive file five time
It is worth to give a try to add PSEUDO_UNLOAD=1 sync before tar. The issue doesn't appear on my CentOS 5.9 after doing that. Best Regards, Zhenhua -Original Message- From: openembedded-core-boun...@lists.openembedded.org [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of Rongqing Li Sent: Thursday, October 17, 2013 10:02 AM To: Richard Purdie Cc: Otavio Salvador; Patches and discussions about the oe-core layer Subject: Re: [OE-core] [PATCH] populate_sdk_base: repeat to tar archive file five time On 10/16/2013 08:12 PM, Richard Purdie wrote: On Wed, 2013-10-16 at 14:34 +0800, Rongqing Li wrote: On 10/16/2013 02:24 PM, Otavio Salvador wrote: On Wed, Oct 16, 2013 at 2:53 AM, rongqing...@windriver.com wrote: From: Roy Li rongqing...@windriver.com [YOCTO #5287] tar failed and reported that file changed as we read it, now we workaround it Signed-off-by: Roy Li rongqing...@windriver.com You must be kidding right?! loop 5 times?!? why not fix the root cause of the change? Sorry, I do not know the root cause, and I see many people spent lots of efforts to investigate, but do not find the root cause, sometime we suspect it is the building servers kernel issue, if it is true, we can not fix the building servers, we only workaround the code. This workaround is not going into master, its horrid. Do we know which versions of the kernel on the server have the issue. I'd much rather tell people to fix their broken filesystems for example and refuse to run on them. I saw it happened on CentOS 5.9 and RedHat 5.5, and We deployed lots of them, it is hard to replace them. The bug did not happen everytime, only intermittently, this workaround is ugly, but it is better than fixing the servers, or declaring them as unsupported server. -Roy Cheers, Richard -- Best Reagrds, Roy | RongQing Li ___ 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] [oe-core][patch v2] sanity.bbclass: correct the gcc_arch check logic
Randy,
Thanks for the update.
Best Regards,
Zhenhua
-Original Message-
From: Randy MacLeod [mailto:randy.macl...@windriver.com]
Sent: Wednesday, July 24, 2013 1:25 AM
To: Luo Zhenhua-B19537
Cc: openembedded-core@lists.openembedded.org; Yu Zongchun-B40527; Hatle,
Mark
Subject: Re: [OE-core] [oe-core][patch v2] sanity.bbclass: correct the
gcc_arch check logic
On 13-07-05 04:23 AM, Luo Zhenhua-B19537 wrote:
Hi Randy,
Any update? Can this patch be applied?
Now sed -e 's/if status != 0/if status == 0/' sanity.bbclass is
needed in my test script to ensure Yocto can work on our build server.
Best Regards,
Zhenhua
Zhenhua,
I apologize for the huge delay (vacation, day job, ...).
Mark and I worked on this and he sent:
commit c126729b29822d3602c9c4fd9016cc79b6057fc5
Author: Mark Hatle mark.ha...@windriver.com
Date: Mon Jul 15 15:10:26 2013 -0500
sanity.bbclass: Update gcc sanity check
which seems like the right solution.
// Randy
-Original Message-
From: Luo Zhenhua-B19537
Sent: Thursday, June 27, 2013 12:04 PM
To: 'Randy MacLeod'
Cc: openembedded-core@lists.openembedded.org; Yu Zongchun-B40527;
Hatle, Mark
Subject: RE: [OE-core] [oe-core][patch v2] sanity.bbclass: correct
the gcc_arch check logic
Randy,
Thanks for the details.
Following is my trial result, FYI.
[b19537@busy ~]$ lsb_release -a
LSB Version: :core-4.0-amd64:core-4.0-ia32:core-4.0-noarch:graphics-
4.0-amd64:graphics-4.0-ia32:graphics-4.0-noarch:printing-4.0-
amd64:printing-4.0-ia32:printing-4.0-noarch
Distributor ID:CentOS
Description: CentOS release 5.9 (Final)
Release: 5.9
Codename: Final
[b19537@busy ~]$
[b19537@busy ~]$ gcc -v
Using built-in specs.
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
-- infodir=/usr/share/info --enable-shared --enable-threads=posix
--enable- checking=release --with-system-zlib --enable-__cxa_atexit
--disable- libunwind-exceptions --enable-libgcj-multifile --enable-
languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk
-- disable-dssi --disable-plugin
--with-java-home=/usr/lib/jvm/java-1.4.2-
gcj-1.4.2.0/jre --with-cpu=generic --host=x86_64-redhat-linux Thread
model: posix gcc version 4.1.2 20080704 (Red Hat 4.1.2-54)
[b19537@busy ~]$ [b19537@busy ~]$ cat gcc_test_new.c int main (){
volatile int atomic = 2; __sync_bool_compare_and_swap (atomic, 2,
3); return 0;} [b19537@busy ~]$ [b19537@busy ~]$ gcc -o gcc_test_new
gcc_test_new.c [b19537@busy ~]$ echo $?
0
[b19537@busy ~]$ gcc -march=native -o gcc_test_new gcc_test_new.c
gcc_test_new.c:1: error: bad value (native) for -march= switch
gcc_test_new.c:1: error: bad value (native) for -mtune= switch
[b19537@busy ~]$ echo $?
1
[b19537@busy ~]$
[b19537@busy ~]$ gcc -march=x86-64 -o gcc_test_new gcc_test_new.c
[b19537@busy ~]$ echo $?
0
[b19537@busy ~]$
Best Regards,
Zhenhua
-Original Message-
From: Randy MacLeod [mailto:randy.macl...@windriver.com]
Sent: Thursday, June 27, 2013 6:17 AM
To: Luo Zhenhua-B19537
Cc: openembedded-core@lists.openembedded.org; Yu Zongchun-B40527;
Hatle, Mark
Subject: Re: [OE-core] [oe-core][patch v2] sanity.bbclass: correct
the gcc_arch check logic
On 13-06-19 11:28 PM, Luo Zhenhua-B19537 wrote:
Ping.
-Original Message-
From: Luo Zhenhua-B19537
Sent: Tuesday, June 18, 2013 9:26 PM
To: 'Richard Purdie'; Randy MacLeod
Cc: openembedded-core@lists.openembedded.org; Yu Zongchun-B40527
Subject: RE: [OE-core] [oe-core][patch v2] sanity.bbclass: correct
the gcc_arch check logic
Hi Randy,
During the test on my machine with gcc-4.1.2, if -march=native is
not supported by host gcc, a non-zero value(256) returns,
otherwise 0
returns.
[LOG]
status is 256
result is gcc_test.c:1: error: bad value (native) for -march=
switch
gcc_test.c:1: error: bad value (native) for -mtune= switch
Please confirm if this is same as your result.
Yes it's essentially the same.
Mark decided that the previous test program that checked for the
existence of:
__GCC_HAVE_SYNC_COMPARE_AND_SWAP_4
would be better done as a check for:
__sync_bool_compare_and_swap
I believe he got the idea from looking at glib's configure script.
I'm working on properly checking on which value to give to march:
native,i686,x86-64. More tomorrow.
// Randy
Test results and prelim code if you are interested.
Here's how that test behaves with the old toolchain:
### What's the host setup?
$ gcc --version
gcc (GCC) 4.1.2 20080704 (Red Hat 4.1.2-54) Copyright (C) 2006 Free
Software Foundation, Inc.
This is free software; see the source for copying conditions. There
is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
$ head -1 /etc/issue
Re: [OE-core] [meta-fsl-ppc][PATCH v3] linux-qoriq-sdk(-headers): upgrade to the version of sdk-1.4
Sorry for sending to the wrong mailing list.
Please ignore.
Best Regards,
Zhenhua
-Original Message-
From: Luo Zhenhua-B19537
Sent: Monday, July 01, 2013 1:51 PM
To: openembedded-core@lists.openembedded.org
Cc: Liu Ting-B28495; Guo Chunrong-B40290; Yu Zongchun-B40527; Luo
Zhenhua-B19537
Subject: [meta-fsl-ppc][PATCH v3] linux-qoriq-sdk(-headers): upgrade to
the version of sdk-1.4
1.Update kernel version to 3.8.
2.add DEPENDS libgcc and append TOOLCHAIN_OPTIONS to KERNEL_{CC,LD}.
kernel in sdk 1.4 need run-time support libraries 'libgcc.a', added in
file arch/powerpc/Makefile:
LIBGCC := $(shell $(CC) $(KBUILD_CFLAGS) -print-libgcc-file-name) Without
passing the TOOLCHAIN_OPTIONS (define --sysroot parameter), it will fail
to find the libgcc.a.
3.Also remove the patches which were already merged on git tree.
Signed-off-by: Zhenhua Luo zhenhua@freescale.com
Signed-off-by: Ting Liu b28...@freescale.com
---
...option-Automount-devtmpfs-at-dev-in-kerne.patch | 78 --
--
...Undef-before-redefining-__attribute_const.patch | 28 ---
...-build-dependencies-for-c-files-requiring.patch | 44 ---
.../linux/files/fix_getrusage_for_perf.patch | 33 -
...efile.headersinst-install-headers-from-sc.patch | 46
recipes-kernel/linux/linux-qoriq-sdk-headers.bb|4 +
recipes-kernel/linux/linux-qoriq-sdk.bb|8 +-
recipes-kernel/linux/linux-qoriq-sdk.inc |7 +-
8 files changed, 57 insertions(+), 191 deletions(-) delete mode 100644
recipes-kernel/linux/files/0001-Enable-the-option-Automount-devtmpfs-at-
dev-in-kerne.patch
delete mode 100644 recipes-kernel/linux/files/0001-compiler.h-Undef-
before-redefining-__attribute_const.patch
delete mode 100644 recipes-kernel/linux/files/0001-powerpc-Fix-build-
dependencies-for-c-files-requiring.patch
delete mode 100644 recipes-
kernel/linux/files/fix_getrusage_for_perf.patch
create mode 100644 recipes-kernel/linux/files/scripts-
Makefile.headersinst-install-headers-from-sc.patch
diff --git a/recipes-kernel/linux/files/0001-Enable-the-option-Automount-
devtmpfs-at-dev-in-kerne.patch b/recipes-kernel/linux/files/0001-Enable-
the-option-Automount-devtmpfs-at-dev-in-kerne.patch
deleted file mode 100644
index 39783ef..000
--- a/recipes-kernel/linux/files/0001-Enable-the-option-Automount-
devtmpfs-at-dev-in-kerne.patch
+++ /dev/null
@@ -1,78 +0,0 @@
-From 3179602e581b6fe8797a5677d5ac4ecfab065cc6 Mon Sep 17 00:00:00 2001
-From: Chunrong Guo b40...@freescale.com
-Date: Thu, 11 Apr 2013 01:52:48 -0500
-Subject: [PATCH] Enable the option Automount devtmpfs at /dev in
kernel
-
-Upstream-Status:Pending
-Signed-off-by: Chunrong Guo b40...@freescale.com
- arch/powerpc/configs/85xx/e6500rev1_defconfig |1 +
- arch/powerpc/configs/corenet32_smp_defconfig |1 +
- arch/powerpc/configs/corenet64_smp_defconfig |1 +
- arch/powerpc/configs/mpc85xx_defconfig|1 +
- arch/powerpc/configs/mpc85xx_smp_defconfig|1 +
- 5 files changed, 5 insertions(+)
-
-diff --git a/arch/powerpc/configs/85xx/e6500rev1_defconfig
b/arch/powerpc/configs/85xx/e6500rev1_defconfig
-index 4b5866d..32ebb50 100644
a/arch/powerpc/configs/85xx/e6500rev1_defconfig
-+++ b/arch/powerpc/configs/85xx/e6500rev1_defconfig
-@@ -72,6 +72,7 @@ CONFIG_IPV6=y
- CONFIG_IP_SCTP=m
- CONFIG_UEVENT_HELPER_PATH=/sbin/hotplug
- CONFIG_DEVTMPFS=y
-+CONFIG_DEVTMPFS_MOUNT=y
- CONFIG_MTD=y
- CONFIG_MTD_CMDLINE_PARTS=y
- CONFIG_MTD_CHAR=y
-diff --git a/arch/powerpc/configs/corenet32_smp_defconfig
b/arch/powerpc/configs/corenet32_smp_defconfig
-index b43d4b6..3fe10e5 100644
a/arch/powerpc/configs/corenet32_smp_defconfig
-+++ b/arch/powerpc/configs/corenet32_smp_defconfig
-@@ -71,6 +71,7 @@ CONFIG_IPV6=y
- CONFIG_IP_SCTP=m
- CONFIG_UEVENT_HELPER_PATH=/sbin/hotplug
- CONFIG_DEVTMPFS=y
-+CONFIG_DEVTMPFS_MOUNT=y
- CONFIG_MTD=y
- CONFIG_MTD_CMDLINE_PARTS=y
- CONFIG_MTD_CHAR=y
-diff --git a/arch/powerpc/configs/corenet64_smp_defconfig
b/arch/powerpc/configs/corenet64_smp_defconfig
-index 13b032b..74cc46a 100644
a/arch/powerpc/configs/corenet64_smp_defconfig
-+++ b/arch/powerpc/configs/corenet64_smp_defconfig
-@@ -66,6 +66,7 @@ CONFIG_IPV6=y
- CONFIG_IP_SCTP=m
- CONFIG_UEVENT_HELPER_PATH=/sbin/hotplug
- CONFIG_DEVTMPFS=y
-+CONFIG_DEVTMPFS_MOUNT=y
- CONFIG_MTD=y
- CONFIG_MTD_CMDLINE_PARTS=y
- CONFIG_MTD_CHAR=y
-diff --git a/arch/powerpc/configs/mpc85xx_defconfig
b/arch/powerpc/configs/mpc85xx_defconfig
-index 8fb742d..f353a6e 100644
a/arch/powerpc/configs/mpc85xx_defconfig
-+++ b/arch/powerpc/configs/mpc85xx_defconfig
-@@ -75,6 +75,7 @@ CONFIG_IPV6=y
- CONFIG_IP_SCTP=m
- CONFIG_UEVENT_HELPER_PATH=/sbin/hotplug
- CONFIG_DEVTMPFS=y
-+CONFIG_DEVTMPFS_MOUNT=y
- CONFIG_MTD=y
- CONFIG_MTD_CHAR=y
- CONFIG_MTD_BLOCK=y
-diff --git a/arch/powerpc/configs/mpc85xx_smp_defconfig
b
Re: [OE-core] [oe-core][patch v2] sanity.bbclass: correct the gcc_arch check logic
Randy,
Thanks for the details.
Following is my trial result, FYI.
[b19537@busy ~]$ lsb_release -a
LSB Version:
:core-4.0-amd64:core-4.0-ia32:core-4.0-noarch:graphics-4.0-amd64:graphics-4.0-ia32:graphics-4.0-noarch:printing-4.0-amd64:printing-4.0-ia32:printing-4.0-noarch
Distributor ID: CentOS
Description:CentOS release 5.9 (Final)
Release:5.9
Codename: Final
[b19537@busy ~]$
[b19537@busy ~]$ gcc -v
Using built-in specs.
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-libgcj-multifile
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk
--disable-dssi --disable-plugin
--with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre --with-cpu=generic
--host=x86_64-redhat-linux
Thread model: posix
gcc version 4.1.2 20080704 (Red Hat 4.1.2-54)
[b19537@busy ~]$
[b19537@busy ~]$ cat gcc_test_new.c
int main (){ volatile int atomic = 2; __sync_bool_compare_and_swap
(atomic, 2, 3); return 0;}
[b19537@busy ~]$
[b19537@busy ~]$ gcc -o gcc_test_new gcc_test_new.c
[b19537@busy ~]$ echo $?
0
[b19537@busy ~]$ gcc -march=native -o gcc_test_new gcc_test_new.c
gcc_test_new.c:1: error: bad value (native) for -march= switch
gcc_test_new.c:1: error: bad value (native) for -mtune= switch
[b19537@busy ~]$ echo $?
1
[b19537@busy ~]$
[b19537@busy ~]$ gcc -march=x86-64 -o gcc_test_new gcc_test_new.c
[b19537@busy ~]$ echo $?
0
[b19537@busy ~]$
Best Regards,
Zhenhua
-Original Message-
From: Randy MacLeod [mailto:randy.macl...@windriver.com]
Sent: Thursday, June 27, 2013 6:17 AM
To: Luo Zhenhua-B19537
Cc: openembedded-core@lists.openembedded.org; Yu Zongchun-B40527; Hatle,
Mark
Subject: Re: [OE-core] [oe-core][patch v2] sanity.bbclass: correct the
gcc_arch check logic
On 13-06-19 11:28 PM, Luo Zhenhua-B19537 wrote:
Ping.
-Original Message-
From: Luo Zhenhua-B19537
Sent: Tuesday, June 18, 2013 9:26 PM
To: 'Richard Purdie'; Randy MacLeod
Cc: openembedded-core@lists.openembedded.org; Yu Zongchun-B40527
Subject: RE: [OE-core] [oe-core][patch v2] sanity.bbclass: correct
the gcc_arch check logic
Hi Randy,
During the test on my machine with gcc-4.1.2, if -march=native is not
supported by host gcc, a non-zero value(256) returns, otherwise 0
returns.
[LOG]
status is 256
result is gcc_test.c:1: error: bad value (native) for -march= switch
gcc_test.c:1: error: bad value (native) for -mtune= switch
Please confirm if this is same as your result.
Yes it's essentially the same.
Mark decided that the previous test program that checked for the
existence of:
__GCC_HAVE_SYNC_COMPARE_AND_SWAP_4
would be better done as a check for:
__sync_bool_compare_and_swap
I believe he got the idea from looking at glib's configure script.
I'm working on properly checking on which value to give to march:
native,i686,x86-64. More tomorrow.
// Randy
Test results and prelim code if you are interested.
Here's how that test behaves with the old toolchain:
### What's the host setup?
$ gcc --version
gcc (GCC) 4.1.2 20080704 (Red Hat 4.1.2-54) Copyright (C) 2006 Free
Software Foundation, Inc.
This is free software; see the source for copying conditions. There is
NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.
$ head -1 /etc/issue
CentOS release 5.9 (Final)
### Old test and results: All options fail, returning a status of 1.
$ gcc -o /tmp/jj /tmp/gcc-jj.c
/tmp/gcc-jj.c: In function ‘main’:
/tmp/gcc-jj.c:1: error: ‘__GCC_HAVE_SYNC_COMPARE_AND_SWAP_4’ undeclared
(first use in this function)
/tmp/gcc-jj.c:1: error: (Each undeclared identifier is reported only once
/tmp/gcc-jj.c:1: error: for each function it appears in.)
$ echo $?
1
$ gcc -march=native -o /tmp/jj /tmp/gcc-jj.c
/tmp/gcc-jj.c:1: error: bad value (native) for -march= switch
/tmp/gcc-jj.c:1: error: bad value (native) for -mtune= switch $ echo $?
1
$ gcc -march=i686 -o /tmp/jj /tmp/gcc-jj.c
/tmp/gcc-jj.c: In function ‘main’:
/tmp/gcc-jj.c:1: error: ‘__GCC_HAVE_SYNC_COMPARE_AND_SWAP_4’ undeclared
(first use in this function)
/tmp/gcc-jj.c:1: error: (Each undeclared identifier is reported only once
/tmp/gcc-jj.c:1: error: for each function it appears in.) $ echo $?
1
### New test and results: -march=`mangle uname -m` works.
$ cat /tmp/gcc_test.c
int main (){ volatile int atomic = 2; __sync_bool_compare_and_swap
(atomic, 2, 3); return 0;}
$ gcc -o /tmp/jj /tmp/gcc_test.c
/tmp/ccEVX7IX.o: In function `main':
gcc_test.c:(.text+0x2f): undefined reference to
`__sync_bool_compare_and_swap_4'
collect2: ld returned 1 exit status
$ echo $?
1
$ gcc -march=native -o /tmp/jj /tmp/gcc_test.c
/tmp/gcc_test.c:1: error: bad value (native
Re: [OE-core] [oe-core][patch v2] sanity.bbclass: correct the gcc_arch check logic
Ping.
-Original Message-
From: Luo Zhenhua-B19537
Sent: Tuesday, June 18, 2013 9:26 PM
To: 'Richard Purdie'; Randy MacLeod
Cc: openembedded-core@lists.openembedded.org; Yu Zongchun-B40527
Subject: RE: [OE-core] [oe-core][patch v2] sanity.bbclass: correct the
gcc_arch check logic
Hi Randy,
During the test on my machine with gcc-4.1.2, if -march=native is not
supported by host gcc, a non-zero value(256) returns, otherwise 0 returns.
[LOG]
status is 256
result is gcc_test.c:1: error: bad value (native) for -march= switch
gcc_test.c:1: error: bad value (native) for -mtune= switch
Please confirm if this is same as your result.
Best Regards,
Zhenhua
-Original Message-
From: Richard Purdie [mailto:richard.pur...@linuxfoundation.org]
Sent: Tuesday, June 18, 2013 9:04 PM
To: Luo Zhenhua-B19537; Randy MacLeod
Cc: openembedded-core@lists.openembedded.org; Yu Zongchun-B40527
Subject: Re: [OE-core] [oe-core][patch v2] sanity.bbclass: correct the
gcc_arch check logic
On Tue, 2013-06-18 at 21:08 +0800, Zhenhua Luo wrote:
The gcc arch check result is incorrect when gcc version is older
than
4.5.
Sanity checker requests user to add -march=native into
BUILD_CFLAGS even if the flag is not supported by host gcc.
The status is 0 when -march=native is supported by host gcc, so set
result to True, otherwise set result to False.
Signed-off-by: Zhenhua Luo zhenhua@freescale.com
---
meta/classes/sanity.bbclass |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/classes/sanity.bbclass
b/meta/classes/sanity.bbclass index 3b9934b..ee09679 100644
--- a/meta/classes/sanity.bbclass
+++ b/meta/classes/sanity.bbclass
@@ -325,7 +325,7 @@ def check_gcc_march(sanity_data):
if status != 0:
# Check if GCC could work with march
status,result =
oe.utils.getstatusoutput(${BUILD_PREFIX}gcc -march=native gcc_test.c
-o
gcc_test)
-if status != 0:
+if status == 0:
result = True
else:
result = False
Can you and Randy please sort out what the correct value is here please.
This appears to directly revert
http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=ad276d7d89190c57a
152
867d7278ee18f784ff2c
Cheers,
Richard
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [oe-core][patch v2] sanity.bbclass: correct the gcc_arch check logic
Hi Randy,
During the test on my machine with gcc-4.1.2, if -march=native is not supported
by host gcc, a non-zero value(256) returns, otherwise 0 returns.
[LOG]
status is 256
result is gcc_test.c:1: error: bad value (native) for -march= switch
gcc_test.c:1: error: bad value (native) for -mtune= switch
Please confirm if this is same as your result.
Best Regards,
Zhenhua
-Original Message-
From: Richard Purdie [mailto:richard.pur...@linuxfoundation.org]
Sent: Tuesday, June 18, 2013 9:04 PM
To: Luo Zhenhua-B19537; Randy MacLeod
Cc: openembedded-core@lists.openembedded.org; Yu Zongchun-B40527
Subject: Re: [OE-core] [oe-core][patch v2] sanity.bbclass: correct the
gcc_arch check logic
On Tue, 2013-06-18 at 21:08 +0800, Zhenhua Luo wrote:
The gcc arch check result is incorrect when gcc version is older than
4.5.
Sanity checker requests user to add -march=native into BUILD_CFLAGS
even if the flag is not supported by host gcc.
The status is 0 when -march=native is supported by host gcc, so set
result to True, otherwise set result to False.
Signed-off-by: Zhenhua Luo zhenhua@freescale.com
---
meta/classes/sanity.bbclass |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/classes/sanity.bbclass b/meta/classes/sanity.bbclass
index 3b9934b..ee09679 100644
--- a/meta/classes/sanity.bbclass
+++ b/meta/classes/sanity.bbclass
@@ -325,7 +325,7 @@ def check_gcc_march(sanity_data):
if status != 0:
# Check if GCC could work with march
status,result =
oe.utils.getstatusoutput(${BUILD_PREFIX}gcc -march=native gcc_test.c -o
gcc_test)
-if status != 0:
+if status == 0:
result = True
else:
result = False
Can you and Randy please sort out what the correct value is here please.
This appears to directly revert
http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=ad276d7d89190c57a152
867d7278ee18f784ff2c
Cheers,
Richard
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] Differnt build result of same u-boot source with differnet binutils
When the u-boot(HEAD of master in git://git.freescale.com/ppc/sdk/u-boot.git) of p1022ds is built with different binutils in Yocto, the result is different. With binutils-2.23.1(last version in Yocto), u-boot can be built correctly. With binutils-2.23.2(current version in Yocto), the build failed as following: | release.S: Assembler messages: | release.S:236: Error: value of 4294963524 too large for field of 2 bytes at 170 | release.S:237: Error: operand out of range (0xf144 is not between 0x and 0x) | release.S:237: Error: value of 4294963524 too large for field of 2 bytes at 174 | release.S:365: Error: value of 4294963524 too large for field of 2 bytes at 206 | release.S:366: Error: operand out of range (0xf144 is not between 0x and 0x) | release.S:366: Error: value of 4294963524 too large for field of 2 bytes at 210 | release.S:390: Error: value of 4294963520 too large for field of 2 bytes at 278 | release.S:391: Error: operand out of range (0xf140 is not between 0x and 0x) | release.S:391: Error: value of 4294963520 too large for field of 2 bytes at 282 Below is the failed code section: [..snip..] 233 #define toreset(x) (x - __secondary_start_page + 0xf000) 234 235 /* get our PIR to figure out our table entry */ 236 lis r3,toreset(__spin_table_addr)@h 237 ori r3,r3,toreset(__spin_table_addr)@l 238 lwz r3,0(r3) [..snip..] Seems like the build error is related to binutils, can somebody shed some light on the issue? Thanks in advance. Best Regards, Zhenhua ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [oe-core][PATCH] apr: fix configure issue for ppc64 targets
Please ignore this patch.
Another patch has been sent out to fix the same issue.
http://patches.openembedded.org/patch/50617/
Best Regards,
Zhenhua
-Original Message-
From: Luo Zhenhua-B19537
Sent: Tuesday, May 28, 2013 5:06 PM
To: openembedded-core@lists.openembedded.org
Cc: Liu Ting-B28495; Guo Chunrong-B40290; Yu Zongchun-B40527; Luo
Zhenhua-B19537
Subject: [oe-core][PATCH] apr: fix configure issue for ppc64 targets
Fix following error of apr configure for powerpc64 targets:
| configure:27173: checking whether TCP_NODELAY and TCP_CORK can both be
| enabled
| configure:27179: error: in `/home/yocto/workspace/sdk-
devel/build_p5020ds-64b_release/tmp/work/ppc64e5500-fsl-linux/apr/1.4.6-
r2/apr-1.4.6':
| configure:27181: error: cannot run test program while cross compiling
Signed-off-by: Zhenhua Luo zhenhua@freescale.com
---
meta/recipes-support/apr/apr_1.4.6.bb |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/meta/recipes-support/apr/apr_1.4.6.bb b/meta/recipes-
support/apr/apr_1.4.6.bb
index 77dffee..a89d25e 100644
--- a/meta/recipes-support/apr/apr_1.4.6.bb
+++ b/meta/recipes-support/apr/apr_1.4.6.bb
@@ -9,7 +9,7 @@ LIC_FILES_CHKSUM =
file://LICENSE;md5=0c35ff3c4c83b89d2f076e315caac28b \
BBCLASSEXTEND = native
-PR = r2
+PR = r3
SRC_URI = ${APACHE_MIRROR}/apr/${BPN}-${PV}.tar.bz2 \
file://configure_fixes.patch \ @@ -23,6 +23,8 @@ inherit
autotools lib_package binconfig multilib_header
OE_BINCONFIG_EXTRA_MANGLE = -e
's:location=source:location=installed:'
+EXTRA_OECONF_powerpc64 += apr_cv_tcp_nodelay_with_cork=yes
+
do_configure_prepend() {
cd ${S}
./buildconf
--
1.7.9.5
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] Query for multilib support in Yocto
Hi Mark,
Thanks for your comments.
-Original Message-
From: openembedded-core-boun...@lists.openembedded.org
[mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of Mark
Hatle
Sent: Thursday, May 23, 2013 10:47 PM
On 5/23/13 3:46 AM, Luo Zhenhua-B19537 wrote:
For gcc with multilib support running on target board 1. Can the same
gcc binary build both 32b and 64b applications or two different gcc
binaries(one is for 32b, the other is for 64b) are required?
As far as I'm aware the same issue above holds true here. You still need
multiple compiler binaries, one for each multilib. (Khem Raj would know
if this is still true however.)
[Luo Zhenhua-B19537] I see an successful case of single gcc on target can build
both 32b and 64b app, https://bugzilla.yoctoproject.org/show_bug.cgi?id=1369.
Is that still true in recent Yocto?
I experienced following error when I use gcc(32bit rootfs with multilib
support) to do 64b build, I find the linker search libraries in /usr/lib
and /lib instead of /usr/lib64 and /lib64.
root@p5020ds:~# gcc -m64 my_test.c -o my_test
/usr/lib/gcc/powerpc-poky-linux/4.7.2/../../../../powerpc-poky-linux/b
in/ld: skipping incompatible
/usr/lib/gcc/powerpc-poky-linux/4.7.2/../../../powerpc-poky-linux/4.7.
2/libgcc.a when searching for -lgcc
/usr/lib/gcc/powerpc-poky-linux/4.7.2/../../../../powerpc-poky-linux/b
in/ld: skipping incompatible
/usr/lib/powerpc-poky-linux/4.7.2/libgcc.a when searching for -lgcc
/usr/lib/gcc/powerpc-poky-linux/4.7.2/../../../../powerpc-poky-linux/b
in/ld: cannot find -lgcc
/usr/lib/gcc/powerpc-poky-linux/4.7.2/../../../../powerpc-poky-linux/b
in/ld: skipping incompatible /lib/../lib/libgcc_s.so.1 when searching
for libgcc_s.so.1
/usr/lib/gcc/powerpc-poky-linux/4.7.2/../../../../powerpc-poky-linux/b
in/ld: skipping incompatible //lib/libgcc_s.so.1 when searching for
libgcc_s.so.1
/usr/lib/gcc/powerpc-poky-linux/4.7.2/../../../../powerpc-poky-linux/b
in/ld: cannot find libgcc_s.so.1
/usr/lib/gcc/powerpc-poky-linux/4.7.2/../../../../powerpc-poky-linux/b
in/ld: skipping incompatible
/usr/lib/gcc/powerpc-poky-linux/4.7.2/../../../powerpc-poky-linux/4.7.
2/libgcc.a when searching for libgcc.a
/usr/lib/gcc/powerpc-poky-linux/4.7.2/../../../../powerpc-poky-linux/b
in/ld: skipping incompatible
/usr/lib/powerpc-poky-linux/4.7.2/libgcc.a when searching for libgcc.a
/usr/lib/gcc/powerpc-poky-linux/4.7.2/../../../../powerpc-poky-linux/b
in/ld: cannot find libgcc.a
Ya, this is running the 'wrong' toolchain. From the errors it appears to
me that it's the 32-bit gcc, attempting to compile for 64-bit. There is
a command that will tell you what architectures gcc was built to support,
but unfortunately I don't remember it offhand.
[Luo Zhenhua-B19537] The test program can be compiled and assembled correctly,
but link failed. Seems like -m64 influenced powerpc-poky-linux-gcc, but not
influenced powerpc-poky-linux-ld, LIBRARY_PATH is same for both 32b and 64b
build, how can the value of LIBRARY_PATH be set to different value if -m64 is
passed?
root@p5020ds:~# gcc -m64 -c my_test.c
root@p5020ds:~# ls -l
total 3
-rw-r--r-- 1 root root 30 May 23 09:40 my_test.c
-rw-r--r-- 1 root root 1208 May 24 08:09 my_test.o
root@p5020ds:~# file my_test.o
my_test.o: ELF 64-bit MSB relocatable, 64-bit PowerPC or cisco 7500, version 1
(SYSV), not stripped
root@p5020ds:~# cat my_test.c
int main()
{
return 0;
}
Best Regards,
Zhenhua
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] Query for multilib support in Yocto
Hi all,
I am trying the multilib feature of Yocto, and I want to make sure if below
scenarios are supported, who can help to clarify? Thanks in advance.
For standalone toolchain built by bitbake meta-toolchain
1. Can the same gcc binary build both 32b and 64b applications or two different
gcc binaries(one is for 32b, the other is for 64b) are required?
For gcc with multilib support running on target board
1. Can the same gcc binary build both 32b and 64b applications or two different
gcc binaries(one is for 32b, the other is for 64b) are required?
2. Can both 32b and 64b application be executed in the same rootfs image with
multilib support?
BTW, may I know how the default value of LIBRARY_PATH is set? I experienced
following error when I use gcc(32bit rootfs with multilib support) to do 64b
build, I find the linker search libraries in /usr/lib and /lib instead of
/usr/lib64 and /lib64.
root@p5020ds:~# gcc -m64 my_test.c -o my_test
/usr/lib/gcc/powerpc-poky-linux/4.7.2/../../../../powerpc-poky-linux/bin/ld:
skipping incompatible
/usr/lib/gcc/powerpc-poky-linux/4.7.2/../../../powerpc-poky-linux/4.7.2/libgcc.a
when searching for -lgcc
/usr/lib/gcc/powerpc-poky-linux/4.7.2/../../../../powerpc-poky-linux/bin/ld:
skipping incompatible /usr/lib/powerpc-poky-linux/4.7.2/libgcc.a when searching
for -lgcc
/usr/lib/gcc/powerpc-poky-linux/4.7.2/../../../../powerpc-poky-linux/bin/ld:
cannot find -lgcc
/usr/lib/gcc/powerpc-poky-linux/4.7.2/../../../../powerpc-poky-linux/bin/ld:
skipping incompatible /lib/../lib/libgcc_s.so.1 when searching for libgcc_s.so.1
/usr/lib/gcc/powerpc-poky-linux/4.7.2/../../../../powerpc-poky-linux/bin/ld:
skipping incompatible //lib/libgcc_s.so.1 when searching for libgcc_s.so.1
/usr/lib/gcc/powerpc-poky-linux/4.7.2/../../../../powerpc-poky-linux/bin/ld:
cannot find libgcc_s.so.1
/usr/lib/gcc/powerpc-poky-linux/4.7.2/../../../../powerpc-poky-linux/bin/ld:
skipping incompatible
/usr/lib/gcc/powerpc-poky-linux/4.7.2/../../../powerpc-poky-linux/4.7.2/libgcc.a
when searching for libgcc.a
/usr/lib/gcc/powerpc-poky-linux/4.7.2/../../../../powerpc-poky-linux/bin/ld:
skipping incompatible /usr/lib/powerpc-poky-linux/4.7.2/libgcc.a when searching
for libgcc.a
/usr/lib/gcc/powerpc-poky-linux/4.7.2/../../../../powerpc-poky-linux/bin/ld:
cannot find libgcc.a
collect2: error: ld returned 1 exit status
root@p5020ds:~# cat my_test.c
int main()
{
int a=0;
return a;
}
Best Regards,
Zhenhua
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] /usr/lib/perl5 conflict in sysroot folder
Recently I met a /usr/lib/perl5 conflict error, following is the details, is there any idea to solve such kind of issue? When perl is built, the output includes /usr/lib/perl folder and /usr/lib/perl5 symbol link, libhugetlbfs also produces /usr/lib/perl5 folder, there might be conflict when doing populate_sysroot, DEPENDS = perl can be added into libhugetlbfs recipe to bypass the issue, but the perl5 symbol link is not available anymore, this should be an incorrect method. Meanwhile, even if above way is used, same error will appear if perl is rebuilt due to perl5 folder of libhugetlbfs exists and perl5 symbol link can't be created. Error log: ERROR: Error executing a python function in /home/yocto/workspace/sdk-devel/poky/meta/recipes-devtools/perl/perl_5.14.3.bb: CalledProcessError: Command 'tar -cf - -C /home/yocto/workspace/sdk-devel/build_t4240qds_release/tmp/work/ppce6500-fsl_networking-linux/perl/5.14.3-r1/sysroot-destdir -ps . | tar -xf - -C /home/yocto/workspace/sdk-devel/build_t4240qds_release/tmp/sysroots/t4240qds' returned non-zero exit status 2 with output tar: ./usr/lib/perl5: Cannot create symlink to `perl': File exists tar: Exiting with failure status due to previous errors Best Regards, Zhenhua ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] The build issue of wayland-native on Linux distros with old glibc
Thanks for the comments and patch, the patch works well during our build test. Best Regards, Zhenhua -Original Message- From: Richard Purdie [mailto:richard.pur...@linuxfoundation.org] Sent: Friday, April 12, 2013 4:42 AM To: Khem Raj Cc: Luo Zhenhua-B19537; Guo Chunrong-B40290; Liu Ting-B28495; openembedded-core@lists.openembedded.org Subject: Re: [OE-core] The build issue of wayland-native on Linux distros with old glibc On Thu, 2013-04-11 at 13:33 -0700, Khem Raj wrote: On Apr 11, 2013, at 2:22 AM, Luo Zhenhua-B19537 b19...@freescale.com wrote: I tried to build wayland-native which requires sys/signalfd.h and sys/timerfd.h, the two headers are not provided by Yocto build env, so host version is searched. those are coming from libc, I don't think we use own libc for native packages. So they have to come from host libc, for nativesdk different story When the build is conducted in Linux distros with old glibc(not sure about the accurate version), above two headers are not available, so build will failed as following: | /home/yocto/workspace/sdk-devel/build_p4080ds_release/tmp/work/x86 | _64-linux/wayland-native/1.0.6-r0/wayland-1.0.6/src/event-loop.c:3 | 3:26: error: sys/signalfd.h: No such file or directory | /home/yocto/workspace/sdk-devel/build_p4080ds_release/tmp/work/x86 | _64-linux/wayland-native/1.0.6-r0/wayland-1.0.6/src/event-loop.c:3 | 4:25: error: sys/timerfd.h: No such file or directory Can anybody shed some light on how to solve the issue in Yocto to ensure the build doesn't depend on host env? https://bugzilla.yoctoproject.org/show_bug.cgi?id=4245 Khem is right, it should be using the host libc but perhaps we can cut down how much of wayland we build natively. Hopefully Ross might have a fix, see the above bug, help testing would be appreciated. Cheers, Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] The build issue of wayland-native on Linux distros with old glibc
I tried to build wayland-native which requires sys/signalfd.h and sys/timerfd.h, the two headers are not provided by Yocto build env, so host version is searched. When the build is conducted in Linux distros with old glibc(not sure about the accurate version), above two headers are not available, so build will failed as following: | /home/yocto/workspace/sdk-devel/build_p4080ds_release/tmp/work/x86_64-linux/wayland-native/1.0.6-r0/wayland-1.0.6/src/event-loop.c:33:26: error: sys/signalfd.h: No such file or directory | /home/yocto/workspace/sdk-devel/build_p4080ds_release/tmp/work/x86_64-linux/wayland-native/1.0.6-r0/wayland-1.0.6/src/event-loop.c:34:25: error: sys/timerfd.h: No such file or directory Can anybody shed some light on how to solve the issue in Yocto to ensure the build doesn't depend on host env? Best Regards, Zhenhua ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Tar failed occasionally during the nativesdk toolchain build
-Original Message- From: Richard Purdie [mailto:richard.pur...@linuxfoundation.org] Sent: Thursday, March 28, 2013 9:39 PM On Wed, 2013-03-27 at 10:55 +, Luo Zhenhua-B19537 wrote: When I build nativesdk toolchain, following build error appears sometimes, any suggestion to solve the issue? tar: ./sysroots/ppce500mc-fsl_networking- linux/var/lib/rpm/__db.002: file changed as we read it Thanks in advance. Sounds like something is still writing to the rpm database whilst we're packaging it which would be bad. More logs/information might help debug it further. [Luo Zhenhua-B19537] Hope following log helpful. | DEBUG: Executing python function do_populate_sdk | DEBUG: Executing shell function populate_sdk_image | Previous repo file missing: /local/cache-build-32bit/poky/build_p4080ds_release_master/tmp/deploy/rpm/all/repodata/primary.xml.gz | Previous repo file missing: /local/cache-build-32bit/poky/build_p4080ds_release_master/tmp/deploy/rpm/i686_nativesdk/repodata/primary.xml.gz | Previous repo file missing: /local/cache-build-32bit/poky/build_p4080ds_release_master/tmp/deploy/rpm/p4080ds/repodata/primary.xml.gz | Previous repo file missing: /local/cache-build-32bit/poky/build_p4080ds_release_master/tmp/deploy/rpm/ppce500mc/repodata/primary.xml.gz | Note: configuring RPM platform settings | Note: configuring RPM system provides | Note: configuring RPM DB settings | Note: configuring Smart settings | | | | | | | Note: adding Smart channel p4080ds (35) | | | Note: adding Smart channel ppce500mc (30) | | | Note: adding Smart channel all (10) | | | Note: configuring RPM cross-install scriptlet_wrapper | | Updating cache... [100%] | | Saving cache... | | Note: adding Smart RPM DB channel | | Note: to be installed: eglibc-staticdev@ppce500mc libgomp-dev@ppce500mc libgomp1@ppce500mc dtc@ppce500mc libglib-2.0-dev@ppce500mc libgomp-staticdev@ppce500mc libglib-2.0-0@ppce500mc packagegroup-core-standalone-sdk-target@all libstdc++-staticdev@ppce500mc | Loading cache... | Updating cache... [100%] | | Computing transaction...error: failed to open /etc/mtab: No such file or directory | Committing transaction... | Preparing... [ 0%] |1:Installing eglibc-gconv [ 2%] |2:Installing eglibc-locale.. [ 4%] |3:Installing libstdc++-sta.. [ 6%] |4:Installing libc6 [ 9%] |5:Installing eglibc-locale.. [ 11%] |6:Installing eglibc-locale.. [ 13%] |7:Installing eglibc-locale.. [ 16%] |8:Installing eglibc-locale.. [ 18%] |9:Installing libgomp-stati.. [ 20%] | 10:Installing linux-qoriq-s.. [ 23%] | 11:Installing eglibc-locale.. [ 25%] | 12:Installing eglibc-locale.. [ 27%] | 13:Installing eglibc-locale.. [ 30%] | 14:Installing libc6-dbg [ 32%] | 15:Installing eglibc-locale.. [ 34%] | 16:Installing eglibc-extra-.. [ 37%] | 17:Installing libgcc1 [ 39%] | 18:Installing eglibc-utils [ 41%] | 19:Installing libsegfault [ 44%] | 20:Installing eglibc-gconv-.. [ 46%] | 21:Installing libthread-db1 [ 48%] | 22:Installing libcidn1 [ 51%] | 23:Installing dtc [ 53%] | 24:Installing libz1 [ 55%] | 25:Installing eglibc-gconv-.. [ 58%] | 26:Installing libffi6 [ 60%] | 27:Installing eglibc-gconv-.. [ 62%] | 28:Installing eglibc-gconv-.. [ 65%] | 29:Installing eglibc-locale.. [ 67%] | 30:Installing eglibc-locale.. [ 69%] | 31:Installing libgomp1
[OE-core] Tar failed occasionally during the nativesdk toolchain build
When I build nativesdk toolchain, following build error appears sometimes, any suggestion to solve the issue? tar: ./sysroots/ppce500mc-fsl_networking-linux/var/lib/rpm/__db.002: file changed as we read it Thanks in advance. Regards, Zhenhua ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] Build issue of nativesdk toolchain
When I build nativesdk toolchain with recent poky + meta-fsl-ppc + FSL SDK
specific layers, build issue similar to error-1 happens. This issue might
appear for different gcc related package during different trial, e.g. libgcc,
gcc, gcc-cross-initial, gcc-crosssdk, etc.
When I revert
http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=9bfd92243eced921f166d84b5a72d6f774e13413,
error-1 build issue goes away, error-2 appears, error-2 also can't be
reproduced every time. Does anyone ever meet the similar build issue and any
comment on the build error?
[Error-1 logs]:
OSError: [Errno 39] Directory not empty:
'/local/cache-build-32bit/poky/build_p1022ds_release_master/tmp/work-shared/gcc-4.7.2+fsl-r19/gcc-4.7.2+fsl/gcc/cp'
ERROR: The stack trace of python calls that resulted in this exception/failure
was:
ERROR: File base_do_unpack, line 19, in module
ERROR:
ERROR: File base_do_unpack, line 14, in base_do_unpack
ERROR:
ERROR: File
/local/cache-build-32bit/poky/bitbake/lib/bb/fetch2/__init__.py, line 1466,
in unpack
ERROR: ud.method.unpack(ud, root, self.d)
ERROR:
ERROR: File /local/cache-build-32bit/poky/bitbake/lib/bb/fetch2/git.py,
line 239, in unpack
ERROR: bb.utils.prunedir(destdir)
ERROR:
ERROR: File /local/cache-build-32bit/poky/bitbake/lib/bb/utils.py, line
561, in prunedir
ERROR: os.rmdir(os.path.join(root, name))
ERROR:
ERROR: The code that was being executed was:
ERROR: 0015:except bb.fetch2.BBFetchException, e:
ERROR: 0016:raise bb.build.FuncFailed(e)
ERROR: 0017:
ERROR: 0018:
ERROR: *** 0019:base_do_unpack(d)
ERROR: 0020:
ERROR: [From file: 'base_do_unpack', lineno: 19, function: module]
ERROR: 0010:rootdir = localdata.getVar('WORKDIR', True)
ERROR: 0011:
ERROR: 0012:try:
ERROR: 0013:fetcher = bb.fetch2.Fetch(src_uri, localdata)
ERROR: *** 0014:fetcher.unpack(rootdir)
ERROR: 0015:except bb.fetch2.BBFetchException, e:
ERROR: 0016:raise bb.build.FuncFailed(e)
ERROR: 0017:
ERROR: 0018:
ERROR: [From file: 'base_do_unpack', lineno: 14, function: base_do_unpack]
ERROR: Function failed: base_do_unpack
ERROR: Logfile of failure stored in:
/local/cache-build-32bit/poky/build_p1022ds_release_master/tmp/work-shared/gcc-4.7.2+fsl-r19/temp/log.do_unpack.13886
[...snip...]
ERROR: Command Error: exit status: 1 Output:
Applying patch optional_libstdc.patch
patching file gcc/cp/g++spec.c
can't find file to patch at input line 30
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--
|Index: gcc-4_7-branch/gcc/doc/invoke.texi
|===
|--- gcc-4_7-branch.orig/gcc/doc/invoke.texi2012-04-10 10:37:09.343387385
-0700
|+++ gcc-4_7-branch/gcc/doc/invoke.texi 2012-04-10 10:37:49.483389340 -0700
--
No file to patch. Skipping patch.
3 out of 3 hunks ignored
can't find file to patch at input line 64
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--
|Index: gcc-4_7-branch/gcc/c-family/c.opt
|===
|--- gcc-4_7-branch.orig/gcc/c-family/c.opt 2012-04-10 10:17:24.667330076
-0700
|+++ gcc-4_7-branch/gcc/c-family/c.opt 2012-04-10 10:37:49.483389340 -0700
--
No file to patch. Skipping patch.
1 out of 1 hunk ignored
patching file gcc/gcc.c
Hunk #1 succeeded at 679 (offset -2 lines).
Patch optional_libstdc.patch does not apply (enforce with -f)
ERROR: Function failed: patch_do_patch
ERROR: Logfile of failure stored in:
/local/cache-build-32bit/poky/build_p1022ds_release_master/tmp/work-shared/gcc-4.7.2+fsl-r19/temp/log.do_patch.13815
[Error-2 logs]:
[...snip...]
| log_check: Using
/local/cache-build-32bit/poky/build_p5020ds-64b_release_master/tmp/work/ppc64e5500-fsl_networking-linux/fsl-toolchain/1.0-r7/temp/log.do_populate_sdk.26285
as logfile
| Logfile is clean
| DEBUG: Shell function populate_sdk_image finished
| DEBUG: SITE files ['endian-big', 'bit-64', 'powerpc-common', 'common-linux',
'common-glibc', 'powerpc-linux', 'powerpc64-linux', 'common']
| DEBUG: Executing shell function create_sdk_files
| DEBUG: Shell function create_sdk_files finished
| DEBUG: SITE files ['endian-big', 'bit-32', 'powerpc-common', 'common-linux',
'common-glibc', 'powerpc32-linux', 'powerpc-linux', 'common']
| DEBUG: Executing shell function create_sdk_files
| DEBUG: Shell function create_sdk_files finished
| DEBUG: Executing shell function tar_sdk
| tar: ./sysroots/ppc64e5500-fsl_networking-linux/var/lib/rpm/__db.002: file
changed as we read it
| DEBUG: Python function do_populate_sdk finished
| ERROR: Function failed: tar_sdk (see
/local/cache-build-32bit/poky/build_p5020ds-64b_release_master/tmp/work/ppc64e5500-fsl_networking-linux/fsl-toolchain/1.0-r7/temp/log.do_populate_sdk.26285
for
Re: [OE-core] Build issue of nativesdk toolchain
FSL gcc source is used for following gcc variants, and other gcc variants use
Yocto default source. +fsl suffix is appended into PV in below gcc recipes.
My understanding is that below gcc variants should use a different build folder
with gcc-crosssdk, am I misunderstanding something?
I might need to unify the source for all gcc variants if Yocto doesn't support
above scenario.
Gcc variants with FSL source:
gcc_4.7.bbappendgcc-cross-canadian_4.7.bbappend gcc-fsl.inc
libgcc_4.7.bbappend
gcc-cross_4.7.bbappend gcc-cross-initial_4.7.bbappend
gcc-runtime_4.7.bbappend
$ cat gcc-fsl.inc
PV = 4.7.2+fsl
BINV = 4.7.2
SRCREV = c88a2f851197a103296175e0a7a1cb94ab91bcc3
SRC_URI = git://git.am.freescale.net/gitolite/sdk/gcc.git;destsuffix=gcc-${PV}
\
file://optional_libstdc.patch \
file://use-defaults.h-and-t-oe-in-B.patch \
file://GLIBC_DYNAMIC_LINKER.patch \
FILESEXTRAPATHS_prepend := ${THISDIR}/files:
Below is the content of the bbappend:
require gcc-fsl.inc
Best Regards,
Zhenhua
-Original Message-
From: Richard Purdie [mailto:richard.pur...@linuxfoundation.org]
Sent: Tuesday, March 26, 2013 11:45 PM
To: Luo Zhenhua-B19537
Cc: openembedded-core@lists.openembedded.org
Subject: Re: [OE-core] Build issue of nativesdk toolchain
On Tue, 2013-03-26 at 14:29 +, Luo Zhenhua-B19537 wrote:
When I build nativesdk toolchain with recent poky + meta-fsl-ppc + FSL
SDK specific layers, build issue similar to error-1 happens. This issue
might appear for different gcc related package during different trial,
e.g. libgcc, gcc, gcc-cross-initial, gcc-crosssdk, etc.
When I revert
http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=9bfd92243eced92
1f166d84b5a72d6f774e13413, error-1 build issue goes away, error-2 appears,
error-2 also can't be reproduced every time. Does anyone ever meet the
similar build issue and any comment on the build error?
It sounds like you've changes in gcc between some of the different
variants, e.g. different patch sets or SRC_URI.
gcc uses a shared source directory so the same patchset must be used for
all variants. It has nothing to do with the above commit.
Cheers,
Richard
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [oe-core v2] rpm: split out run-postinsts
-Original Message-
From: openembedded-core-boun...@lists.openembedded.org
[mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of
Mark Hatle
Sent: Saturday, March 23, 2013 1:05 AM
On 3/22/13 11:29 AM, Richard Purdie wrote:
On Thu, 2013-03-21 at 10:05 +0800, Zhenhua Luo wrote:
Split out run-postinsts script into separated package, sometimes only
the postinsts script is required to run all postinsts scripts in
/etc/rpm-postinsts/ instead of the whole rpm package.
@@ -223,9 +223,11 @@ FILES_${PN} = ${bindir}/rpm \
${libdir}/rpm/bin/wget \
/var/lib/rpm \
/var/cache/rpm \
- ${sysconfdir}/rcS.d/S${POSTINSTALL_INITPOSITION}run-postinsts
\
+FILES_${PN}-postinsts =
${sysconfdir}/rcS.d/S${POSTINSTALL_INITPOSITION}run-postinsts \
+
+
FILES_${PN}-dbg += ${libdir}/rpm/.debug \
${libdir}/rpm/bin/.debug \
Don't we need to depend on this package somewhere so that it gets
installed?
I think it should be required from the rootfs_rpm.bbclass in some way.
[Luo Zhenhua-B19537] Is following the right way to include the rpm-postinsts
into rootfs or any better idea? Below patch is verified to be working.
--- a/meta/classes/rootfs_rpm.bbclass
+++ b/meta/classes/rootfs_rpm.bbclass
@@ -35,6 +35,8 @@ opkglibdir = ${localstatedir}/lib/opkg
RPMOPTS=--dbpath ${rpmlibdir}
RPM=rpm ${RPMOPTS}
+IMAGE_INSTALL += rpm-postinsts
+
# RPM doesn't work with multiple rootfs generation at once due to collisions
in the use of files
# in ${DEPLOY_DIR_RPM}. This can be removed if package_update_index_rpm can be
called concurrently
do_rootfs[lockfiles] += ${DEPLOY_DIR_RPM}/rpm.lock
Best Regards,
Zhenhua
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [oe-core] rpm: fix probably redundant RPATH issue
The issue can be reproduced with FSL toolchain which has not been published
yet.
I am not sure if the issue can be reproduced with Yocto default toolchain.
Best Regards,
Zhenhua
-Original Message-
From: Richard Purdie [mailto:richard.pur...@linuxfoundation.org]
Sent: Thursday, March 21, 2013 5:32 PM
To: Luo Zhenhua-B19537
Cc: openembedded-core@lists.openembedded.org; Guo Chunrong-B40290
Subject: Re: [OE-core] [oe-core] rpm: fix probably redundant RPATH issue
On Thu, 2013-03-21 at 15:00 +0800, Zhenhua Luo wrote:
Clear the rpath define to fix below build issue:
ERROR: QA Issue: rpm-build:
/work/ppce500mc-fsl_networking-linux/rpm/5.4.9-r61/packages-split/rpm-
build/usr/lib/rpm/bin/sqlite3 contains probably-redundant RPATH
/usr/lib/../lib
ERROR: QA Issue: rpm-build:
/work/ppce500mc-fsl_networking-linux/rpm/5.4.9-r61/packages-split/rpm-
build/usr/lib/rpm/bin/cp contains probably-redundant RPATH
/usr/lib/../lib ...
Signed-off-by: Zhenhua Luo zhenhua@freescale.com
---
meta/recipes-devtools/rpm/rpm_5.4.9.bb |5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/meta/recipes-devtools/rpm/rpm_5.4.9.bb
b/meta/recipes-devtools/rpm/rpm_5.4.9.bb
index cfdc390..12a1642 100644
--- a/meta/recipes-devtools/rpm/rpm_5.4.9.bb
+++ b/meta/recipes-devtools/rpm/rpm_5.4.9.bb
@@ -43,7 +43,7 @@ LICENSE = LGPLv2.1
LIC_FILES_CHKSUM =
file://COPYING.LIB;md5=2d5025d4aa3495befef8f17206a5b0a1
DEPENDS = libpcre attr acl popt ossp-uuid file bison-native
-PR = r62
+PR = r63
# rpm2cpio is a shell script, which is part of the rpm src.rpm. It
is needed # in order to extract the distribution SRPM into a format we
can extract...
@@ -368,6 +368,9 @@ 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
+# Clear hardcode_libdir_flag_spec to avoid redundant rpath
definition
+sed -i
+ 's/hardcode_libdir_flag_spec=$lt.*/hardcode_libdir_flag_spec=/g'
+ ${S}/configure
+
export varprefix=${localstatedir}
oe_runconf
}
We're seeing a few of these and we're going to end up adding this hack to
every recipe. I'd like to figure out what in libtool is doing this and
fix the libtool patches so it doesn't happen. There must be some path
normalisation issue in there somewhere.
Is there an easy way to reproduce this issue?
Cheers,
Richard
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [oe-core] rpm: split out run-postinsts
-Original Message-
From: Mark Hatle [mailto:mark.ha...@windriver.com]
Sent: Thursday, March 21, 2013 2:58 AM
On 3/20/13 1:52 PM, Saul Wold wrote:
On 03/20/2013 02:39 AM, Zhenhua Luo wrote:
Split out run-postinsts script into separated package, sometimes only
the postinsts script is required to run all postinsts scripts in
/etc/rpm-postinsts/ instead of the whole rpm package
So are you trying to build a system that uses RPM to install the
initial rootfs, but you don't want RPM actually installed?
That seems reasonable to me. I hadn't realized that it was rolled into
the target RPM package like this. In early implementations this script
was installed directly by the rootfs_rpm.
[Luo Zhenhua-B19537] Yes, in my use case, I only need the postinits script
instead of whole rpm package.
Signed-off-by: Zhenhua Luo zhenhua@freescale.com
---
meta/recipes-devtools/rpm/rpm_5.4.9.bb |6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-devtools/rpm/rpm_5.4.9.bb
b/meta/recipes-devtools/rpm/rpm_5.4.9.bb
index 6286771..896e3a4 100644
--- a/meta/recipes-devtools/rpm/rpm_5.4.9.bb
+++ b/meta/recipes-devtools/rpm/rpm_5.4.9.bb
@@ -43,7 +43,7 @@ LICENSE = LGPLv2.1
LIC_FILES_CHKSUM =
file://COPYING.LIB;md5=2d5025d4aa3495befef8f17206a5b0a1
DEPENDS = libpcre attr acl popt ossp-uuid file bison-native
-PR = r61
+PR = r62
# rpm2cpio is a shell script, which is part of the rpm src.rpm. It
is needed
# in order to extract the distribution SRPM into a format we can
extract...
@@ -223,9 +223,11 @@ FILES_${PN} = ${bindir}/rpm \
${libdir}/rpm/bin/wget \
/var/lib/rpm \
/var/cache/rpm \
- ${sysconfdir}/rcS.d/S${POSTINSTALL_INITPOSITION}run-postinsts
\
+FILES_${PN}-postinsts =
${sysconfdir}/rcS.d/S${POSTINSTALL_INITPOSITION}run-postinsts \
+
+
This does not look right to me, you seem to be missing a PACKAGES
entry for the postinsts package. So this really won't do anything.
[Luo Zhenhua-B19537] I will submit v2 to add the entry.
Best Regards,
Zhenhua
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [oe-core master v2] elfutils: Fix size passed to snprintf for invalid sh_name case
V3 is sent out to include a new patch for this build issue, please ignore this
one.
Best Regards,
Zhenhua
-Original Message-
From: Luo Zhenhua-B19537
Sent: Tuesday, March 12, 2013 11:59 AM
To: openembedded-core@lists.openembedded.org
Cc: Liu Ting-B28495; Guo Chunrong-B40290; Luo Zhenhua-B19537
Subject: [oe-core master v2] elfutils: Fix size passed to snprintf for
invalid sh_name case
Following build error will appear on Fedora18.
nm.c: In function 'show_symbols_sysv':
nm.c:756:27: error: argument to 'sizeof' in 'snprintf' call is the same
expression as the destination; did you mean to provide an explicit length?
[-Werror=sizeof-pointer-memaccess]
snprintf (name, sizeof name, [invalid sh_name %# PRIx32 ],
^
Signed-off-by: Zhenhua Luo zhenhua@freescale.com
---
...ssed-to-snprintf-for-invalid-sh_name-case.patch | 27
meta/recipes-devtools/elfutils/elfutils_0.148.bb |3 +-
2 files changed, 29 insertions(+), 1 deletions(-) create mode 100644
meta/recipes-devtools/elfutils/elfutils/nm-Fix-size-passed-to-snprintf-
for-invalid-sh_name-case.patch
diff --git a/meta/recipes-devtools/elfutils/elfutils/nm-Fix-size-passed-
to-snprintf-for-invalid-sh_name-case.patch b/meta/recipes-
devtools/elfutils/elfutils/nm-Fix-size-passed-to-snprintf-for-invalid-
sh_name-case.patch
new file mode 100644
index 000..2b5dad3
--- /dev/null
+++ b/meta/recipes-devtools/elfutils/elfutils/nm-Fix-size-passed-to-snpr
+++ intf-for-invalid-sh_name-case.patch
@@ -0,0 +1,27 @@
+Upstream-Status: Backport
+
+nm: Fix size passed to snprintf for invalid sh_name case.
+native build failed as following on Fedora18:
+nm.c: In function 'show_symbols_sysv':
+nm.c:756:27: error: argument to 'sizeof' in 'snprintf' call is the same
expression as the destination; did you mean to provide an explicit length?
[-Werror=sizeof-pointer-memaccess]
+snprintf (name, sizeof name, [invalid sh_name %# PRIx32 ],
+ ^
+
+The original commit is
+http://git.fedorahosted.org/cgit/elfutils.git/commit/src/nm.c?id=57bd66
+cabf6e6b9ecf622cdbf350804897a8df58
+
+Signed-off-by: Zhenhua Luo zhenhua@freescale.com
+
+--- elfutils-0.148/src/nm.c.org 2013-03-11 22:36:11.0 -0500
elfutils-0.148/src/nm.c 2013-03-11 22:46:09.0 -0500
+@@ -752,8 +752,9 @@
+gelf_getshdr (scn, shdr_mem)-sh_name);
+ if (unlikely (name == NULL))
+ {
+- name = alloca (sizeof [invalid sh_name 0x12345678]);
+- snprintf (name, sizeof name, [invalid sh_name %# PRIx32 ],
++ const size_t bufsz = sizeof [invalid sh_name 0x12345678];
++ name = alloca (bufsz);
++ snprintf (name, bufsz, [invalid sh_name %# PRIx32 ],
+ gelf_getshdr (scn, shdr_mem)-sh_name);
+ }
+ scnnames[elf_ndxscn (scn)] = name;
diff --git a/meta/recipes-devtools/elfutils/elfutils_0.148.bb
b/meta/recipes-devtools/elfutils/elfutils_0.148.bb
index 45931b0..bc9e9c6 100644
--- a/meta/recipes-devtools/elfutils/elfutils_0.148.bb
+++ b/meta/recipes-devtools/elfutils/elfutils_0.148.bb
@@ -6,7 +6,7 @@ LIC_FILES_CHKSUM =
file://COPYING;md5=0636e73ff0215e8d672dc4c32c317bb3\
file://EXCEPTION;md5=570adcb0c1218ab57f2249c67d0ce417
DEPENDS = libtool bzip2 zlib virtual/libintl
-PR = r9
+PR = r10
SRC_URI = https://fedorahosted.org/releases/e/l/elfutils/elfutils-
${PV}.tar.bz2
@@ -31,6 +31,7 @@ SRC_URI += \
file://mempcpy.patch \
file://fix_for_gcc-4.7.patch \
file://dso-link-change.patch \
+ file://nm-Fix-size-passed-to-snprintf-for-invalid-sh_name-
case.patch \
# Only apply when building uclibc based target recipe
SRC_URI_append_libc-uclibc = file://uclibc-support.patch
--
1.7.5.4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [oe-core master] elfutils: Fix size passed to snprintf for invalid sh_name case
Please ignore the patch, v2 has been sent out to fix a semi-colon missing
issue.
Best Regards,
Zhenhua
-Original Message-
From: Luo Zhenhua-B19537
Sent: Tuesday, March 12, 2013 11:34 AM
To: openembedded-core@lists.openembedded.org
Cc: Liu Ting-B28495; Luo Zhenhua-B19537
Subject: [oe-core master] elfutils: Fix size passed to snprintf for
invalid sh_name case
Following build error will appear on Fedora18.
nm.c: In function 'show_symbols_sysv':
nm.c:756:27: error: argument to 'sizeof' in 'snprintf' call is the same
expression as the destination; did you mean to provide an explicit length?
[-Werror=sizeof-pointer-memaccess]
snprintf (name, sizeof name, [invalid sh_name %# PRIx32 ],
^
Signed-off-by: Zhenhua Luo zhenhua@freescale.com
---
...ssed-to-snprintf-for-invalid-sh_name-case.patch | 29
meta/recipes-devtools/elfutils/elfutils_0.148.bb |3 +-
2 files changed, 31 insertions(+), 1 deletions(-) create mode 100644
meta/recipes-devtools/elfutils/elfutils/nm-Fix-size-passed-to-snprintf-
for-invalid-sh_name-case.patch
diff --git a/meta/recipes-devtools/elfutils/elfutils/nm-Fix-size-passed-
to-snprintf-for-invalid-sh_name-case.patch b/meta/recipes-
devtools/elfutils/elfutils/nm-Fix-size-passed-to-snprintf-for-invalid-
sh_name-case.patch
new file mode 100644
index 000..f8e88a2
--- /dev/null
+++ b/meta/recipes-devtools/elfutils/elfutils/nm-Fix-size-passed-to-snpr
+++ intf-for-invalid-sh_name-case.patch
@@ -0,0 +1,29 @@
+Upstream-Status: Backport
+
+nm: Fix size passed to snprintf for invalid sh_name case.
+native build failed as following on Fedora18:
+nm.c: In function 'show_symbols_sysv':
+nm.c:756:27: error: argument to 'sizeof' in 'snprintf' call is the same
expression as the destination; did you mean to provide an explicit length?
[-Werror=sizeof-pointer-memaccess]
+snprintf (name, sizeof name, [invalid sh_name %# PRIx32 ],
+ ^
+
+The original commit is
+http://git.fedorahosted.org/cgit/elfutils.git/commit/src/nm.c?id=57bd66
+cabf6e6b9ecf622cdbf350804897a8df58
+
+Signed-off-by: Zhenhua Luo zhenhua@freescale.com
+
+--- elfutils-0.148/src/nm.c.org 2013-03-11 22:09:13.0 -0500
elfutils-0.148/src/nm.c 2013-03-11 22:11:00.0 -0500
+@@ -752,9 +752,10 @@
+gelf_getshdr (scn, shdr_mem)-sh_name);
+ if (unlikely (name == NULL))
+ {
+- name = alloca (sizeof [invalid sh_name 0x12345678]);
+- snprintf (name, sizeof name, [invalid sh_name %# PRIx32 ],
+-gelf_getshdr (scn, shdr_mem)-sh_name);
++ const size_t bufsz = sizeof [invalid sh_name 0x12345678]
++ name = alloca (bufsz);
++ snprintf (name, bufsz, [invalid sh_name %# PRIx32 ],
++ gelf_getshdr (scn, shdr_mem)-sh_name);
+ }
+ scnnames[elf_ndxscn (scn)] = name;
+ }
diff --git a/meta/recipes-devtools/elfutils/elfutils_0.148.bb
b/meta/recipes-devtools/elfutils/elfutils_0.148.bb
index 45931b0..bc9e9c6 100644
--- a/meta/recipes-devtools/elfutils/elfutils_0.148.bb
+++ b/meta/recipes-devtools/elfutils/elfutils_0.148.bb
@@ -6,7 +6,7 @@ LIC_FILES_CHKSUM =
file://COPYING;md5=0636e73ff0215e8d672dc4c32c317bb3\
file://EXCEPTION;md5=570adcb0c1218ab57f2249c67d0ce417
DEPENDS = libtool bzip2 zlib virtual/libintl
-PR = r9
+PR = r10
SRC_URI = https://fedorahosted.org/releases/e/l/elfutils/elfutils-
${PV}.tar.bz2
@@ -31,6 +31,7 @@ SRC_URI += \
file://mempcpy.patch \
file://fix_for_gcc-4.7.patch \
file://dso-link-change.patch \
+ file://nm-Fix-size-passed-to-snprintf-for-invalid-sh_name-
case.patch \
# Only apply when building uclibc based target recipe
SRC_URI_append_libc-uclibc = file://uclibc-support.patch
--
1.7.5.4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Difference of toolchain recipes
Can anybody shed some light, please? Best Regards, Zhenhua -Original Message- From: Luo Zhenhua-B19537 Sent: Tuesday, December 04, 2012 11:53 AM To: openembedded-core@lists.openembedded.org; 'yo...@yoctoproject.org' Subject: Difference of toolchain recipes It is a bit confused for the different recipes of toolchian, can somebody help to explain what's the difference for those recipes? E.g. gcc-cross, gcc-cross-canadian, gcc-cross-initial, gcc-cross-intermediate, gcc- crosssdk, gcc-crosssdk-initial, gcc-crosssdk-intermediate, gcc-runtime, etc. Is there any document for those description? Best Regards, Zhenhua ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [oe-commits] Zhenhua Luo : libxml2: add --with-fexceptions in configure flags to support exception handling in C++ programs
Thanks for the comment, I will submit a patch to fix it.
Best Regards,
Zhenhua
-Original Message-
From: Martin Jansa [mailto:martin.ja...@gmail.com]
Sent: Tuesday, December 04, 2012 5:26 PM
To: Luo Zhenhua-B19537
Cc: openembedded-comm...@lists.openembedded.org; openembedded-
c...@lists.openembedded.org
Subject: Re: [oe-commits] Zhenhua Luo : libxml2: add --with-fexceptions
in configure flags to support exception handling in C++ programs
On Mon, Dec 03, 2012 at 02:49:22PM +, g...@git.openembedded.org wrote:
Module: openembedded-core.git
Branch: master
Commit: ff5552a8432298c32aec2ace72656b0d7059dad3
URL:http://git.openembedded.org/?p=openembedded-
core.gita=commit;h=ff5552a8432298c32aec2ace72656b0d7059dad3
Author: Zhenhua Luo b19...@freescale.com
Date: Fri Nov 30 08:31:57 2012 +
libxml2: add --with-fexceptions in configure flags to support
exception handling in C++ programs
Without this flag, the library has a problem with C++ programs using
exception handling.
Signed-off-by: Zhenhua Luo b19...@freescale.com
Signed-off-by: Saul Wold s...@linux.intel.com
Signed-off-by: Richard Purdie richard.pur...@linuxfoundation.org
---
meta/recipes-core/libxml/libxml2.inc |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/meta/recipes-core/libxml/libxml2.inc
b/meta/recipes-core/libxml/libxml2.inc
index 9ec507b..615c89e 100644
--- a/meta/recipes-core/libxml/libxml2.inc
+++ b/meta/recipes-core/libxml/libxml2.inc
@@ -9,6 +9,8 @@ LIC_FILES_CHKSUM =
file://Copyright;md5=bb90c48926316d9af6e2d70ca7013ade \
file://list.c;beginline=4;endline=13;md5=cdbfa3dee51c099edb04e39f762ee907
\
file://trio.c;beginline=5;endline=14;md5=6c025753c86d958722ec76e94cae932e
+INC_PR = r1
+
This does not help at all.
opembedded-core/meta/recipes-core/libxml $ grep -R PR.= .
./libxml2.inc:INC_PR = r1
./libxml2_2.9.0.bb:PR = r0
Change PR in ./libxml2_2.9.0.bb to PR = ${INC_PR}.0 if you want to use
INC_PR.
Cheers,
DEPENDS_class-native = python-native
DEPENDS =+ zlib
@@ -24,7 +26,7 @@ do_configure_prepend () {
sed -i -e '/.*ansidecl.h.*/d' ${S}/configure.in }
-EXTRA_OECONF = --without-python --without-debug --without-legacy --
without-catalog --without-docbook --with-c14n --without-lzma
+EXTRA_OECONF = --without-python --without-debug --without-legacy --
without-catalog --without-docbook --with-c14n --without-lzma --with-
fexceptions
EXTRA_OECONF_class-native = --with-python=${STAGING_BINDIR}/python --
without-legacy --with-catalog --without-docbook --with-c14n --without-
lzma
EXTRA_OECONF_class-nativesdk = --with-python=${STAGING_BINDIR}/python
--without-legacy --with-catalog --without-docbook --with-c14n --without-
lzma
EXTRA_OECONF_linuxstdbase = --without-python --with-debug --with-
legacy --with-catalog --with-docbook --with-c14n --without-lzma
___
Openembedded-commits mailing list
openembedded-comm...@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-commi
ts
--
Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] Difference of toolchain recipes
It is a bit confused for the different recipes of toolchian, can somebody help to explain what's the difference for those recipes? E.g. gcc-cross, gcc-cross-canadian, gcc-cross-initial, gcc-cross-intermediate, gcc-crosssdk, gcc-crosssdk-initial, gcc-crosssdk-intermediate, gcc-runtime, etc. Is there any document for those description? Best Regards, Zhenhua ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [Yocto] [meta-fsl-ppc denzil v2] cryptodev kernel module recipe
Wrong operation, please ignore.
Best Regards,
Zhenhua
-Original Message-
From: yocto-boun...@linux.freescale.net [mailto:yocto-
boun...@linux.freescale.net] On Behalf Of Luo Zhenhua-B19537
Sent: Wednesday, November 21, 2012 3:32 PM
To: yo...@linux.freescale.net; openembedded-core@lists.openembedded.org
Cc: Dutta Yashpal-B05456
Subject: [Yocto] [meta-fsl-ppc denzil v2] cryptodev kernel module recipe
From: Yashpal Dutta yashpal.du...@freescale.com
This is a /dev/crypto device driver, equivalent to those in OpenBSD or
FreeBSD.
The main idea is to access of existing ciphers in kernel space from
userspace, thus enabling re-use of a hardware implementation of a cipher.
Signed-off-by: Yashpal Dutta yashpal.du...@freescale.com
---
meta/recipes-kernel/cryptodev/cryptodev_1.5.bb | 17 +
.../cryptodev/files/makefile_fixup.patch | 26
2 files changed, 43 insertions(+), 0 deletions(-) create mode 100644
meta/recipes-kernel/cryptodev/cryptodev_1.5.bb
create mode 100644 meta/recipes-
kernel/cryptodev/files/makefile_fixup.patch
diff --git a/meta/recipes-kernel/cryptodev/cryptodev_1.5.bb
b/meta/recipes-kernel/cryptodev/cryptodev_1.5.bb
new file mode 100644
index 000..0696e2a
--- /dev/null
+++ b/meta/recipes-kernel/cryptodev/cryptodev_1.5.bb
@@ -0,0 +1,17 @@
+SECTION = devel
+SUMMARY = Linux Cryptodev KERNEL MODULE
+DESCRIPTION = The Cryptodev package contains the kernel /dev/crypto
module
+LICENSE = GPLv2
+LIC_FILES_CHKSUM = file://COPYING;md5=b234ee4d69f5fce4486a80fdaf4a4263
+RCONFLICTS_${PN} = ocf-linux
+
+inherit module
+
+SRCREV = 1c24a0aa996630518d47826a2e3fea129ea094c7
+
+SRC_URI = git://repo.or.cz/cryptodev-linux.git;protocol=git \
+ file://makefile_fixup.patch
+
+EXTRA_OEMAKE='KERNEL_DIR=${STAGING_KERNEL_DIR} PREFIX=${D}'
+
+S = ${WORKDIR}/git
diff --git a/meta/recipes-kernel/cryptodev/files/makefile_fixup.patch
b/meta/recipes-kernel/cryptodev/files/makefile_fixup.patch
new file mode 100644
index 000..323aacd
--- /dev/null
+++ b/meta/recipes-kernel/cryptodev/files/makefile_fixup.patch
@@ -0,0 +1,26 @@
+diff --git a/Makefile b/Makefile
+index 2be8825..b36d68c 100644
+--- a/Makefile
b/Makefile
+@@ -1,6 +1,7 @@
+ KBUILD_CFLAGS += -I$(src)
+ KERNEL_DIR = /lib/modules/$(shell uname -r)/build VERSION = 1.5
++PREFIX =
+
+ cryptodev-objs = ioctl.o main.o cryptlib.o authenc.o zc.o util.o
+
+@@ -12,10 +13,10 @@ build: version.h
+ version.h: Makefile
+ @echo #define VERSION \$(VERSION)\ version.h
+
+-install:
++modules_install:
+ make -C $(KERNEL_DIR) SUBDIRS=`pwd` modules_install
+-@echo Installing cryptodev.h in /usr/include/crypto ...
+-@install -D crypto/cryptodev.h /usr/include/crypto/cryptodev.h
++@echo Installing cryptodev.h in $(PREFIX)/usr/include/crypto ...
++@install -D crypto/cryptodev.h
++$(PREFIX)/usr/include/crypto/cryptodev.h
+
+ clean:
+ make -C $(KERNEL_DIR) SUBDIRS=`pwd` clean
___
Yocto mailing list
yo...@linux.freescale.net
http://linux.freescale.net/mailman/listinfo/yocto
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [oe-core] valgrind: fix debug info reading error when do memcheck on ppc targets
-Original Message- From: McClintock Matthew-B29882 Sent: Wednesday, September 12, 2012 12:03 PM diff --git a/meta/recipes-devtools/valgrind/valgrind-3.7.0/valgrind-3.7.0-fix-err or-of-reading-debug-info.patch b/meta/recipes-devtools/valgrind/valgrind-3.7.0/valgrind-3.7.0-fix-err or-of-reading-debug-info.patch Patch needs Upstream-Status: [Luo Zhenhua-B19537] should the status be Pending if the patch has not been sent to upstream? +SRC_URI_append_powerpc = file://valgrind-3.7.0-fix-error-of-reading- debug-info.patch +SRC_URI_append_powerpc64 = file://valgrind-3.7.0-fix-error-of- reading-debug-info.patch [Luo Zhenhua-B19537] I think it is better to keep it for PPC before the issue is reported on targets of other arch. Best Regards, Zhenhua ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [oe-core] linux-dtb: add multi-dtb build support
Sorry for the late response.
I think this issue(2769) has been closed. Doesn't it make sense to generate the
dtb with the same name with corresponding dts?
Best Regards,
Zhenhua
-Original Message-
From: McClintock Matthew-B29882
Sent: Friday, July 20, 2012 10:42 PM
To: Patches and discussions about the oe-core layer; Luo Zhenhua-B19537
Subject: Re: [OE-core] [oe-core] linux-dtb: add multi-dtb build support
Zhenhua,
Any update here?
-M
On Mon, Jul 16, 2012 at 5:50 PM, Matthew McClintock m...@freescale.com
wrote:
Adding Zhenhua so he sees the email for sure ;)
-M
On Mon, Jul 16, 2012 at 5:48 PM, Saul Wold s...@linux.intel.com wrote:
On 06/25/2012 08:53 PM, b19...@freescale.com wrote:
From: Zhenhua Luo b19...@freescale.com
including following enhancement:
* support multi-dtb build
* skip dtb build and install when KERNEL_DEVICETREE is empty
* print a warning message when specified dts file is not
available
Signed-off-by: Zhenhua Luo b19...@freescale.com
---
meta/recipes-kernel/linux/linux-dtb.inc | 36
+--
1 files changed, 29 insertions(+), 7 deletions(-)
This patch appears to rename the .dtb file different than it did
before this change. Is that correct?
Seem to change it from:
uImage-mpc8315e-rdb.dtb
to
uImage-mpc8315erdb.dtb
While the .bin file is still: uImage-mpc8315e-rdb.bin
Inquiring minds?? This was filed as bug 2769
https://bugzilla.yoctoproject.org/show_bug.cgi?id=2769
Thanks
Sau!
diff --git a/meta/recipes-kernel/linux/linux-dtb.inc
b/meta/recipes-kernel/linux/linux-dtb.inc
index 9188cee..8aa1458 100644
--- a/meta/recipes-kernel/linux/linux-dtb.inc
+++ b/meta/recipes-kernel/linux/linux-dtb.inc
@@ -15,13 +15,35 @@ python __anonymous () {
do_install_append() {
if test -n ${KERNEL_DEVICETREE}; then
- dtc -I dts -O dtb ${KERNEL_DEVICETREE_FLAGS} -o devicetree
${KERNEL_DEVICETREE}
- install -m 0644 devicetree ${D}/boot/devicetree-${KERNEL_VERSION}
- install -d ${DEPLOYDIR}
- install -m 0644 devicetree
${DEPLOYDIR}/${KERNEL_IMAGE_BASE_NAME}.dtb
- cd ${DEPLOYDIR}
- rm -f ${KERNEL_IMAGE_SYMLINK_NAME}.dtb
- ln -sf ${KERNEL_IMAGE_BASE_NAME}.dtb
${KERNEL_IMAGE_SYMLINK_NAME}.dtb
+for DTS_FILE in ${KERNEL_DEVICETREE}; do
+if [ ! -f ${DTS_FILE} ]; then
+echo Warning: ${DTS_FILE} is not available!
+continue
+fi
+DTS_BASE_NAME=`basename ${DTS_FILE} | awk -F .
+ '{print
$1}'`
+DTB_NAME=`echo ${KERNEL_IMAGE_BASE_NAME} | sed
s/${MACHINE}/${DTS_BASE_NAME}/g`
+DTB_SYMLINK_NAME=`echo ${KERNEL_IMAGE_SYMLINK_NAME} |
+ sed
s/${MACHINE}/${DTS_BASE_NAME}/g`
+dtc -I dts -O dtb ${KERNEL_DEVICETREE_FLAGS} -o
${DTS_BASE_NAME} ${DTS_FILE}
+install -m 0644 ${DTS_BASE_NAME}
${D}/boot/devicetree-${DTB_SYMLINK_NAME}.dtb
+done
fi
}
+do_deploy_append() {
+if test -n ${KERNEL_DEVICETREE}; then
+for DTS_FILE in ${KERNEL_DEVICETREE}; do
+if [ ! -f ${DTS_FILE} ]; then
+echo Warning: ${DTS_FILE} is not available!
+continue
+fi
+DTS_BASE_NAME=`basename ${DTS_FILE} | awk -F .
+'{print
$1}'`
+DTB_NAME=`echo ${KERNEL_IMAGE_BASE_NAME} | sed
s/${MACHINE}/${DTS_BASE_NAME}/g`
+DTB_SYMLINK_NAME=`echo ${KERNEL_IMAGE_SYMLINK_NAME} |
+ sed
s/${MACHINE}/${DTS_BASE_NAME}/g`
+install -d ${DEPLOYDIR}
+install -m 0644 ${B}/${DTS_BASE_NAME}
${DEPLOYDIR}/${DTB_NAME}.dtb
+cd ${DEPLOYDIR}
+ln -sf ${DTB_NAME}.dtb ${DTB_SYMLINK_NAME}.dtb
+cd -
+done
+fi
+}
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] Different behavior of same IMAGE_FSTYPES definition in edison branch and denzil branch
I meet a different behavior of IMAGE_FSTYPES in edison branch and denzil branch. In edison branch: IMAGE_FSTYPES is defined as following in poky/meta/conf/bitbake.conf. IMAGE_FSTYPES ?= tar.gz I defined IMAGE_FSTYPES as following in my customized image bb file(in my layer) IMAGE_FSTYPES ?= tar.gz ext2.gz.u-boot jffs2 The actual value of IMAGE_FSTYPES is tar.gz ext2.gz.u-boot jffs2 which is the expectation. In denzil branch: IMAGE_FSTYPES is defined as following in poky/meta/conf/bitbake.conf. IMAGE_FSTYPES ?= tar.gz I defined IMAGE_FSTYPES as following in my customized image bb file(in my layer) IMAGE_FSTYPES ?= tar.gz ext2.gz.u-boot jffs2 The actual value of IMAGE_FSTYPES is tar.gz Is this the expected behavior in denzil branch? Should I use 'IMAGE_FSTYPES = tar.gz ext2.gz.u-boot jffs2' to override previous definition? Best Regards, Zhenhua ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] task-core-sdk.bb: add libgomp and libgomp-dev
Richard,
Thanks for your comments, I will submit new version to use RRECOMMENDS.
Best Regards,
Zhenhua
-Original Message-
From: openembedded-core-boun...@lists.openembedded.org
[mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of
Richard Purdie
Sent: Wednesday, July 11, 2012 9:29 PM
To: Patches and discussions about the oe-core layer
Subject: Re: [OE-core] [PATCH] task-core-sdk.bb: add libgomp and libgomp-
dev
On Wed, 2012-07-11 at 20:01 +0800, b19...@freescale.com wrote:
From: Zhenhua Luo b19...@freescale.com
Signed-off-by: Zhenhua Luo b19...@freescale.com
---
meta/recipes-core/tasks/task-core-sdk.bb |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/meta/recipes-core/tasks/task-core-sdk.bb
b/meta/recipes-core/tasks/task-core-sdk.bb
index ec6cdcc..3ee29ce 100644
--- a/meta/recipes-core/tasks/task-core-sdk.bb
+++ b/meta/recipes-core/tasks/task-core-sdk.bb
@@ -7,7 +7,7 @@ LICENSE = MIT
LIC_FILES_CHKSUM =
file://${COREBASE}/LICENSE;md5=3f40d7994397109285ec7b81fdeb3b58 \
file://${COREBASE}/meta/COPYING.MIT;md5=3da9cfbcb788c80a0384361b4de20420
DEPENDS = task-core-console
-PR = r7
+PR = r8
ALLOW_EMPTY = 1
#PACKAGEFUNCS =+ 'generate_sdk_pkgs'
@@ -34,6 +34,8 @@ RDEPENDS_task-core-sdk = \
gettext \
make \
intltool \
+libgomp \
+libgomp-dev \
libstdc++ \
libstdc++-dev \
libtool \
This will break for architectures which don't build libgomp (anything not
powerpc).
You could add a RRECOMMENDS?
Cheers,
Richard
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH oe-core v6] linux-dtb: add multi-dtb build support and keep dtb in deploy cache package
Saul,
In this patch, dtb files are installed into ${D} and ${DEPLOYDIR} by
kernel_do_deploy, there is a race issue of do_deploy and do_package.
do_package runs before dtb are installed into ${D}, so there is no dtb in
/boot/devicetree/ and kernel-devicetree binary package is not generated due to
empty content.
I will send out a patch to do ${D} install and ${DEPLOYDIR} install in
separated steps: do_install and do_deploy.
Best Regards,
Zhenhua
-Original Message-
From: Saul Wold [mailto:s...@linux.intel.com]
Sent: Tuesday, January 10, 2012 1:43 PM
To: Patches and discussions about the oe-core layer
Cc: Luo Zhenhua-B19537
Subject: Re: [OE-core] [PATCH oe-core v6] linux-dtb: add multi-dtb build
support
and keep dtb in deploy cache package
On 01/08/2012 07:37 PM, b19...@freescale.com wrote:
From: Zhenhua Luob19...@freescale.com
Signed-off-by: Zhenhua Luob19...@freescale.com
---
meta/recipes-kernel/linux/linux-dtb.inc | 24 +++-
1 files changed, 15 insertions(+), 9 deletions(-)
diff --git a/meta/recipes-kernel/linux/linux-dtb.inc b/meta/recipes-
kernel/linux/linux-dtb.inc
index 7ec7584..fc29d14 100644
--- a/meta/recipes-kernel/linux/linux-dtb.inc
+++ b/meta/recipes-kernel/linux/linux-dtb.inc
@@ -13,15 +13,21 @@ python __anonymous () {
d.setVar(PACKAGES, %s kernel-devicetree % packages)
}
I am not sure how this worked, I am seeing a problem with building rootfs.
|
kernel-devicetree is needed by
kernel-modules-
3.0.14+git1+6ae3d992cf546184010e87a0349810198f1d167c_1+58ffdb8000e34d2ba7c3ef278
b26680b0886e8b5-r2.mpc8315e_rdb
This might be a PR Bump issue?
Sau!
-do_install_append() {
+kernel_do_deploy_append() {
if test -n ${KERNEL_DEVICETREE}; then
- dtc -I dts -O dtb ${KERNEL_DEVICETREE_FLAGS} -o devicetree
${KERNEL_DEVICETREE}
- install -m 0644 devicetree ${D}/boot/devicetree-${KERNEL_VERSION}
- install -d ${DEPLOY_DIR_IMAGE}
- install -m 0644 devicetree
${DEPLOY_DIR_IMAGE}/${KERNEL_IMAGE_BASE_NAME}.dtb
- cd ${DEPLOY_DIR_IMAGE}
- rm -f ${KERNEL_IMAGE_SYMLINK_NAME}.dtb
- ln -sf ${KERNEL_IMAGE_BASE_NAME}.dtb ${KERNEL_IMAGE_SYMLINK_NAME}.dtb
+for DTS_FILE in ${KERNEL_DEVICETREE}; do
+DTS_BASE_NAME=`basename ${DTS_FILE} | awk -F . '{print $1}'`
+DTB_NAME=`echo ${KERNEL_IMAGE_BASE_NAME} | sed
s/${MACHINE}/${DTS_BASE_NAME}/g`
+DTB_SYMLINK_NAME=`echo ${KERNEL_IMAGE_SYMLINK_NAME} | sed
s/${MACHINE}/${DTS_BASE_NAME}/g`
+dtc -I dts -O dtb ${KERNEL_DEVICETREE_FLAGS} -o devicetree
${DTS_FILE}
+install -m 0644 devicetree
${D}/boot/devicetree-${DTS_BASE_NAME}-
${KERNEL_VERSION}
+
+install -d ${DEPLOYDIR}
+install -m 0644 devicetree ${DEPLOYDIR}/${DTB_NAME}.dtb
+rm -f devicetree
+cd ${DEPLOYDIR}
+ln -sf ${DTB_NAME}.dtb ${DTB_SYMLINK_NAME}.dtb
+cd -
+done
fi
}
-
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] FSLONLY: adjust the meta-oe layer sequence to make Yocto pick up the right bbclass file
Please ignore.
Best Regards,
Zhenhua
-Original Message-
From: Luo Zhenhua-B19537
Sent: Monday, January 09, 2012 4:58 PM
To: openembedded-core@lists.openembedded.org
Cc: Luo Zhenhua-B19537
Subject: [PATCH] FSLONLY: adjust the meta-oe layer sequence to make Yocto pick
up the right bbclass file
From: Zhenhua Luo b19...@freescale.com
Signed-off-by: Zhenhua Luo b19...@freescale.com
---
fsl-setup-poky | 14 +++---
1 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/fsl-setup-poky b/fsl-setup-poky index a5cc702..d1faaae 100755
--- a/fsl-setup-poky
+++ b/fsl-setup-poky
@@ -168,13 +168,6 @@ echo build_${BOARD}_release/conf/local.conf
sed / \/d build_${BOARD}_release/conf/bblayers.conf
build_${BOARD}_release/conf/bblayers.conf~
mv build_${BOARD}_release/conf/bblayers.conf~
build_${BOARD}_release/conf/bblayers.conf
-# append meta-oe/meta-oe if it exists
-if [ -e $CUR_DIR/meta-oe/meta-oe ]; then
-echo $CUR_DIR/meta-oe/meta-oe \\
build_${BOARD}_release/conf/bblayers.conf
-elif [ -e $CUR_DIR/../meta-oe/meta-oe ]; then
-echo $CUR_DIR/../meta-oe/meta-oe \\
build_${BOARD}_release/conf/bblayers.conf
-fi
-
# append meta-fsl-ppc bblayer into conf/bblayers.conf echo
${META_FSL_PPC_LAYER_PATH} \\ build_${BOARD}_release/conf/bblayers.conf
@@ -191,6 +184,13 @@ if [ -e $CUR_DIR/meta-fsl-local-sdk ]; then elif [ -e
$CUR_DIR/../meta-fsl-local-sdk ]; then
echo $CUR_DIR/../meta-fsl-local-sdk \\
build_${BOARD}_release/conf/bblayers.conf
fi
+
+# append meta-oe/meta-oe if it exists
+if [ -e $CUR_DIR/meta-oe/meta-oe ]; then
+echo $CUR_DIR/meta-oe/meta-oe \\
+build_${BOARD}_release/conf/bblayers.conf
+elif [ -e $CUR_DIR/../meta-oe/meta-oe ]; then
+echo $CUR_DIR/../meta-oe/meta-oe \\
+build_${BOARD}_release/conf/bblayers.conf
+fi
echo \ build_${BOARD}_release/conf/bblayers.conf
# enable 64b multilib if we are a p5020ds(-32b)
--
1.7.0.4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [CONSOLIDATED PULL 00/28] Build Fixes and Updates
-Original Message-
From: openembedded-core-boun...@lists.openembedded.org [mailto:openembedded-
core-boun...@lists.openembedded.org] On Behalf Of Richard Purdie
Sent: Friday, January 06, 2012 6:16 AM
To: McClintock Matthew-B29882; Patches and discussions about the oe-core layer
Subject: Re: [OE-core] [CONSOLIDATED PULL 00/28] Build Fixes and Updates
On Thu, 2012-01-05 at 15:57 +, McClintock Matthew-B29882 wrote:
On Thu, Jan 5, 2012 at 5:30 AM, Richard Purdie
richard.pur...@linuxfoundation.org wrote:
Zhenhua Luo (1):
linux-dtb: add multi-dtb build support and keep dtb in deploy cache
package
This looks like it should be done in do_deploy and doesn't fix the
real problem just adding some races in.
Can you add a bit more info here? Should we be building all the device
trees in do_deploy? What races are added?
I guess what I'm asking is why this isn't happening in kernel_do_deploy (with
an
append) and installing the files into ${DEPLOYDIR}? It seems to be appending
to
do_install instead and this confuses the purposes of the different tasks.
If the files were placed into ${DEPLOYDIR} as part of do_deploy, things would
be
much more consistent.
[Luo Zhenhua-B19537] I think you point is to merge do_install_append and
do_deploy_append to do_deploy_append, right?
Best Regards,
Zhenhua
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH oe-core] valgrind: add powerpc to the compatible host and add ${TCLIBC}-dbg in RRECOMMENDS
A new version is submitted according to the comments.
Best Regards,
Zhenhua
-Original Message-
From: Luo Zhenhua-B19537
Sent: Wednesday, January 04, 2012 11:34 AM
To: openembedded-core@lists.openembedded.org
Cc: Luo Zhenhua-B19537
Subject: [PATCH oe-core] valgrind: add powerpc to the compatible host and add
${TCLIBC}-dbg in RRECOMMENDS
From: Zhenhua Luo b19...@freescale.com
1. add powerpc into the compatible host list
2. valgrind requires the non-stripped libraries of ${TCLIBC}, so add
${TCLIBC}-dbg into RRECOMMENDS_valgrind
Signed-off-by: Zhenhua Luo b19...@freescale.com
---
meta/recipes-devtools/valgrind/valgrind_3.7.0.bb |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-devtools/valgrind/valgrind_3.7.0.bb b/meta/recipes-
devtools/valgrind/valgrind_3.7.0.bb
index 03cdd28..1a4fdfd 100644
--- a/meta/recipes-devtools/valgrind/valgrind_3.7.0.bb
+++ b/meta/recipes-devtools/valgrind/valgrind_3.7.0.bb
@@ -7,7 +7,7 @@ LIC_FILES_CHKSUM =
file://COPYING;md5=c46082167a314d785d012a244748d803 \
file://include/valgrind.h;beginline=1;endline=56;md5=aee56014c1dd64260a59fd4df38
752f6 \
file://COPYING.DOCS;md5=8fdeb5abdb235a08e76835f8f3260215
DEPENDS = virtual/libx11
-PR = r0
+PR = r1
SRC_URI = http://www.valgrind.org/downloads/valgrind-${PV}.tar.bz2 \
file://fix_issue_caused_by_ccache.patch \ @@ -18,7 +18,7 @@ SRC_URI =
http://www.valgrind.org/downloads/valgrind-${PV}.tar.bz2 \ SRC_URI[md5sum] =
a855fda56edf05614f099dca316d1775
SRC_URI[sha256sum] =
5d62c0330f1481fe2c593249192fa68ff454c19c34343978cc9ce91aa324cbf6
-COMPATIBLE_HOST = '(i.86|x86_64).*-linux'
+COMPATIBLE_HOST = '(i.86|x86_64|powerpc|ppc|powerpc64|ppc64).*-linux'
inherit autotools
@@ -27,3 +27,5 @@ EXTRA_OEMAKE = -w
PARALLEL_MAKE =
FILES_${PN}-dbg += ${libdir}/${PN}/*/.debug/*
+
+RRECOMMENDS_${PN} += ${TCLIBC}-dbg
--
1.7.0.4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH oe-core v4] linux-dtb: add multi-dtb build support and keep dtb in deploy cache package
= is needless, I will fix the error. Seems it doesn't impact the result. :)
Best Regards,
Zhenhua
-Original Message-
From: Saul Wold [mailto:s...@linux.intel.com]
Sent: Friday, January 06, 2012 3:06 PM
To: Patches and discussions about the oe-core layer
Cc: Luo Zhenhua-B19537
Subject: Re: [OE-core] [PATCH oe-core v4] linux-dtb: add multi-dtb build
support
and keep dtb in deploy cache package
On 01/05/2012 09:57 PM, b19...@freescale.com wrote:
From: Zhenhua Luob19...@freescale.com
Signed-off-by: Zhenhua Luob19...@freescale.com
---
meta/recipes-kernel/linux/linux-dtb.inc | 30
+
-
1 files changed, 21 insertions(+), 9 deletions(-)
diff --git a/meta/recipes-kernel/linux/linux-dtb.inc b/meta/recipes-
kernel/linux/linux-dtb.inc
index 7ec7584..5439810 100644
--- a/meta/recipes-kernel/linux/linux-dtb.inc
+++ b/meta/recipes-kernel/linux/linux-dtb.inc
@@ -13,15 +13,27 @@ python __anonymous () {
d.setVar(PACKAGES, %s kernel-devicetree % packages)
}
-do_install_append() {
+kernel_do_deploy_append() {
if test -n ${KERNEL_DEVICETREE}; then
- dtc -I dts -O dtb ${KERNEL_DEVICETREE_FLAGS} -o devicetree
${KERNEL_DEVICETREE}
- install -m 0644 devicetree ${D}/boot/devicetree-${KERNEL_VERSION}
- install -d ${DEPLOY_DIR_IMAGE}
- install -m 0644 devicetree
${DEPLOY_DIR_IMAGE}/${KERNEL_IMAGE_BASE_NAME}.dtb
- cd ${DEPLOY_DIR_IMAGE}
- rm -f ${KERNEL_IMAGE_SYMLINK_NAME}.dtb
- ln -sf ${KERNEL_IMAGE_BASE_NAME}.dtb ${KERNEL_IMAGE_SYMLINK_NAME}.dtb
+for DTS_FILE in ${KERNEL_DEVICETREE}; do
+DTS_BASE_NAME=`basename ${DTS_FILE} | awk -F . '{print $1}'`
+DTB_NAME=`echo ${KERNEL_IMAGE_BASE_NAME} | sed
s/${MACHINE}/${DTS_BASE_NAME}/g`
+DTB_SYMLINK_NAME=`echo ${KERNEL_IMAGE_SYMLINK_NAME} | sed
s/${MACHINE}/${DTS_BASE_NAME}/g`
+dtc -I dts -O dtb ${KERNEL_DEVICETREE_FLAGS} -o devicetree
${DTS_FILE}
+install -m 0644 devicetree
${D}/boot/devicetree-${DTS_BASE_NAME}-
${KERNEL_VERSION}
+install -d ${DEPLOY_DIR_IMAGE}
+install -m 0644 devicetree ${DEPLOY_DIR_IMAGE}/${DTB_NAME}.dtb
+rm -f devicetree
+cd ${DEPLOY_DIR_IMAGE}
+rm -f ${DTB_SYMLINK_NAME}.dtb
+ln -sf ${DTB_NAME}.dtb ${DTB_SYMLINK_NAME}.dtb
+cd -
+
+install -d ${DEPLOYDIR}
+install -m 0644 ${DEPLOY_DIR_IMAGE}/${DTB_NAME}.dtb
${DEPLOYDIR}/${DTB_NAME}.dtb
+cd ${DEPLOYDIR}
+ln -sf ${DTB_NAME}.dtb ${DTB_SYMLINK_NAME=}.dtb
Should there be an '=' at the end of this?
Sau!
+cd -
+done
fi
}
-
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v2 oe-core] valgrind: add powerpc to the compatible host and add ${TCLIBC}-dbg in RRECOMMENDS
Since valgrind has been upgraded to 3.7.0, a new patch to add powerpc support
will be submitted, please ignore this one.
Best Regards,
Zhenhua
-Original Message-
From: Luo Zhenhua-B19537
Sent: Thursday, December 29, 2011 10:39 AM
To: openembedded-core@lists.openembedded.org
Cc: Luo Zhenhua-B19537
Subject: [PATCH v2 oe-core] valgrind: add powerpc to the compatible host and
add
${TCLIBC}-dbg in RRECOMMENDS
From: Zhenhua Luo b19...@freescale.com
1. add powerpc into the compatible host list
2. valgrind requires the non-stripped libraries of ${TCLIBC}, so add
${TCLIBC}-dbg into RRECOMMENDS_valgrind
Signed-off-by: Zhenhua Luo b19...@freescale.com
---
meta/recipes-devtools/valgrind/valgrind_3.6.1.bb |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-devtools/valgrind/valgrind_3.6.1.bb b/meta/recipes-
devtools/valgrind/valgrind_3.6.1.bb
index 021caa8..2abe173 100644
--- a/meta/recipes-devtools/valgrind/valgrind_3.6.1.bb
+++ b/meta/recipes-devtools/valgrind/valgrind_3.6.1.bb
@@ -7,7 +7,7 @@ LIC_FILES_CHKSUM =
file://COPYING;md5=c46082167a314d785d012a244748d803 \
file://include/valgrind.h;beginline=1;endline=56;md5=13a71cedba99112334d8596162a
ec37e \
file://COPYING.DOCS;md5=8fdeb5abdb235a08e76835f8f3260215
DEPENDS = virtual/libx11
-PR = r1
+PR = r2
SRC_URI = http://www.valgrind.org/downloads/valgrind-${PV}.tar.bz2 \
file://fix_issue_caused_by_ccache.patch \ @@ -17,7 +17,7 @@ SRC_URI =
http://www.valgrind.org/downloads/valgrind-${PV}.tar.bz2 \ SRC_URI[md5sum] =
2c3aa122498baecc9d69194057ca88f5
SRC_URI[sha256sum] =
49bdcc4fbcf060049b5f0dcfd8a187a6e90e0b0e57309f633b64e44430726a0e
-COMPATIBLE_HOST = '(i.86|x86_64).*-linux'
+COMPATIBLE_HOST = '(i.86|x86_64|powerpc|ppc|powerpc64|ppc64).*-linux'
inherit autotools
@@ -26,3 +26,5 @@ EXTRA_OEMAKE = -w
PARALLEL_MAKE =
FILES_${PN}-dbg += ${libdir}/${PN}/*/.debug/*
+
+RRECOMMENDS_${PN} += ${TCLIBC}-dbg
--
1.7.0.4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH oe-core] valgrind: add powerpc to the compatible host and add eglibc-dbg in rdepends
-Original Message- From: openembedded-core-boun...@lists.openembedded.org [mailto:openembedded- core-boun...@lists.openembedded.org] On Behalf Of Phil Blundell Sent: Thursday, December 29, 2011 4:20 AM On Wed, 2011-12-28 at 09:14 +, Paul Eggleton wrote: On Wednesday 28 December 2011 14:55:08 b19...@freescale.com wrote: +RDEPENDS += eglibc-dbg So I might be completely off-base here having never tried it, but what if you're using uclibc? I don't really understand why valgrind is doing that at all. [Luo Zhenhua-B19537] The reason is that valgrind requires non-stripped libraries of glibc during running. Best Regards, Zhenhua ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH oe-core] valgrind: add powerpc to the compatible host and add eglibc-dbg in rdepends
Thanks for the good suggestions, a new version will be submitted.
Best Regards,
Zhenhua
-Original Message-
From: McClintock Matthew-B29882
Sent: Thursday, December 29, 2011 3:39 AM
To: Patches and discussions about the oe-core layer
Cc: McClintock Matthew-B29882; Garg Vakul-B16394; Luo Zhenhua-B19537
Subject: Re: [OE-core] [PATCH oe-core] valgrind: add powerpc to the compatible
host and add eglibc-dbg in rdepends
On Wed, Dec 28, 2011 at 6:15 AM, Martin Jansa martin.ja...@gmail.com wrote:
If a dependency on the libc debug packages is really needed you
could do something this instead:
RRECOMMENDS_${PN} += ${TCLIBC}-dbg
This seems better since it include uclibc if that was selected...
Or:
RECOMMENDS_libc-glibc = glibc-dbg
with extra R and PN, right?
RRECOMMENDS_${PN}_libc-glibc = glibc-dbg
This is only provided by eglibc now, so it leaves out uclibc... I think...
-M
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v2 oe-core] linux-dtb: add dtb into deploy cache package
Please ignore.
A new version will be submitted.
Best Regards,
Zhenhua
-Original Message-
From: Luo Zhenhua-B19537
Sent: Friday, December 23, 2011 11:00 AM
To: openembedded-core@lists.openembedded.org
Cc: Luo Zhenhua-B19537
Subject: [PATCH v2 oe-core] linux-dtb: add dtb into deploy cache package
From: Zhenhua Luo b19...@freescale.com
current dtb is not included in the deploy cache package, dtb is missing
when build kernel from caches
Signed-off-by: Zhenhua Luo b19...@freescale.com
---
meta/recipes-kernel/linux/linux-dtb.inc |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/meta/recipes-kernel/linux/linux-dtb.inc b/meta/recipes-
kernel/linux/linux-dtb.inc
index 7ec7584..e537d86 100644
--- a/meta/recipes-kernel/linux/linux-dtb.inc
+++ b/meta/recipes-kernel/linux/linux-dtb.inc
@@ -25,3 +25,11 @@ do_install_append() {
fi
}
+do_deploy_append() {
+if test -n ${KERNEL_DEVICETREE}; then
+install -d ${DEPLOYDIR}
+install -m 0644 ${DEPLOY_DIR_IMAGE}/${KERNEL_IMAGE_BASE_NAME}.dtb
${DEPLOYDIR}/${KERNEL_IMAGE_BASE_NAME}.dtb
+cd ${DEPLOYDIR}
+ln -sf ${KERNEL_IMAGE_BASE_NAME}.dtb ${KERNEL_IMAGE_SYMLINK_NAME}.dtb
+fi
+}
--
1.7.0.4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH oe-core] linux-dtb: add dtb into deploy cache package
Hello Saul,
-Original Message-
From: Saul Wold [mailto:s...@linux.intel.com]
Sent: Friday, December 23, 2011 5:56 AM
+do_deploy_append() {
+install -d ${DEPLOYDIR}
+install -m 0644 ${DEPLOY_DIR_IMAGE}/${KERNEL_IMAGE_BASE_NAME}.dtb
${DEPLOYDIR}/${KERNEL_IMAGE_BASE_NAME}.dtb
+cd ${DEPLOYDIR}
+ln -sf ${KERNEL_IMAGE_BASE_NAME}.dtb
+${KERNEL_IMAGE_SYMLINK_NAME}.dtb }
What machines did you test this on? Is it possible that some kernels do not
generate .dtb files?
[Luo Zhenhua-B19537] I verified on Freescale powerpc platforms, this will cause
error on targets which don't need dtb. I will post a new patch to fix the
issue.
Best Regards,
Zhenhua
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH oe-core] valgrind: add powerpc into the compatible host list
Can somebody confirm whether valgrind works for armv4/v5, please? Best Regards, Zhenhua -Original Message- From: openembedded-core-boun...@lists.openembedded.org [mailto:openembedded- core-boun...@lists.openembedded.org] On Behalf Of Sergey Lapin Sent: Thursday, December 22, 2011 7:09 PM To: Patches and discussions about the oe-core layer Subject: Re: [OE-core] [PATCH oe-core] valgrind: add powerpc into the compatible host list On Wed, Dec 21, 2011 at 9:07 PM, Richard Purdie richard.pur...@linuxfoundation.org wrote: On Wed, 2011-12-21 at 06:21 +, Luo Zhenhua-B19537 wrote: Since nobody confirm that it works on mips, I will create a new patch to define COMPATIBLE_HOST as following, does it make sense? COMPATIBLE_HOST = '(i.86|x86_64|powerpc|powerpc64|ppc|ppc64|arm).*- linux' Does it really work on armv4/v5? S. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH oe-core] valgrind: add powerpc into the compatible host list
Sure, if valgrind can work on x86, powerpc, arm, COMPATIBLE_HOST can be
removed, I will post a v2 patch.
Best Regards,
Zhenhua
-Original Message-
From: openembedded-core-boun...@lists.openembedded.org [mailto:openembedded-
core-boun...@lists.openembedded.org] On Behalf Of Koen Kooi
Sent: Monday, December 19, 2011 6:30 PM
To: Patches and discussions about the oe-core layer
Subject: Re: [OE-core] [PATCH oe-core] valgrind: add powerpc into the
compatible
host list
Op 19 dec. 2011, om 11:12 heeft b19...@freescale.com b19...@freescale.com
het volgende geschreven:
From: Zhenhua Luo b19...@freescale.com
add powerpc/powerpc64/ppc/ppc64 in COMPATIBLE_HOST variable
Since valgrind works on arm as well it might be better just to drop the
COMPATIBLE_HOST, no?
regards,
Koen
Signed-off-by: Zhenhua Luo b19...@freescale.com
---
meta/recipes-devtools/valgrind/valgrind_3.6.1.bb |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-devtools/valgrind/valgrind_3.6.1.bb
b/meta/recipes-devtools/valgrind/valgrind_3.6.1.bb
index 021caa8..c09fc41 100644
--- a/meta/recipes-devtools/valgrind/valgrind_3.6.1.bb
+++ b/meta/recipes-devtools/valgrind/valgrind_3.6.1.bb
@@ -7,7 +7,7 @@ LIC_FILES_CHKSUM =
file://COPYING;md5=c46082167a314d785d012a244748d803 \
file://include/valgrind.h;beginline=1;endline=56;md5=13a71cedba99112334d8596162a
ec37e \
file://COPYING.DOCS;md5=8fdeb5abdb235a08e76835f8f3260215
DEPENDS = virtual/libx11
-PR = r1
+PR = r2
SRC_URI = http://www.valgrind.org/downloads/valgrind-${PV}.tar.bz2 \
file://fix_issue_caused_by_ccache.patch \ @@ -17,7 +17,7 @@
SRC_URI = http://www.valgrind.org/downloads/valgrind-${PV}.tar.bz2 \
SRC_URI[md5sum] = 2c3aa122498baecc9d69194057ca88f5
SRC_URI[sha256sum] =
49bdcc4fbcf060049b5f0dcfd8a187a6e90e0b0e57309f633b64e44430726a0e
-COMPATIBLE_HOST = '(i.86|x86_64).*-linux'
+COMPATIBLE_HOST = '(i.86|x86_64|powerpc|powerpc64|ppc|ppc64).*-linux'
inherit autotools
--
1.7.0.4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] after modifying source code in work/, how to rebuild package?
-Original Message- From: openembedded-core-boun...@lists.openembedded.org [mailto:openembedded- core-boun...@lists.openembedded.org] On Behalf Of Lauri Hintsala Sent: Friday, December 16, 2011 4:14 PM To: openembedded-core@lists.openembedded.org Subject: Re: [OE-core] after modifying source code in work/, how to rebuild package? Sorry, this workflow will clean all your changes. How about that: bitbake projectname -c compile -f bitbake projectname [Luo Zhenhua-B19537] Those commands should work. Best Regards, Zhenhua ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
