date:20140918


On 2014年09月18日 22:13, Mark Hatle wrote:

On 9/18/14, 8:58 AM, Mark Hatle wrote:

On 9/18/14, 2:19 AM, Khem Raj wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1



On 9/16/14 8:06 AM, Kai Kang wrote:

Redefine dynamic linker for aarch64 from /lib to /lib64.

BASELIB of aarch64 has to be defined with 'lib64', then linker file
ld-linux-aarch64.so.1 is installed into /lib64 rather than /lib. So
update it here too.


hmmm since the ldso name is different it can still live in /lib
and there will be ilp32 version ldso multilib as well later. can we 
keep

ldso in /lib ?


I thought the upstream definition (managed by ARM Ltd, and Linaro) 
for the ld.so
had changed a few months back so that /lib64 was the 'standard' 
location for the

ldso. Perhaps I'm mistaken?


I did some research and I'm confused.. aarch64 is screwed up by 
consensus apparently..


Dynamic libraries live in /lib64, and the dynamic linker in /lib.. Whee!

So ya, this patch isn't correct.. the dynamic linker needs to stay in 
/lib. (Nothing says you can't sym/hardlink to lib64.. but it has to 
refer to in in /lib for the ABI conformance.)


OK. Keep dynamic linker in /lib and change libraries directory from 
/lib64 to /lib.


--Kai



--Mark


--Mark



Signed-off-by: Kai Kang 
---
meta/recipes-devtools/gcc/gcc-4.9.inc | 1 +
.../0056-redefine-dynamic-linker-for-aarch64.patch | 34 
++

2 files changed, 35 insertions(+)
create mode 100644 
meta/recipes-devtools/gcc/gcc-4.9/0056-redefine-dynamic-linker-for-aarch64.patch


diff --git a/meta/recipes-devtools/gcc/gcc-4.9.inc 
b/meta/recipes-devtools/gcc/gcc-4.9.inc

index 25778bd..c434a45 100644
--- a/meta/recipes-devtools/gcc/gcc-4.9.inc
+++ b/meta/recipes-devtools/gcc/gcc-4.9.inc
@@ -70,6 +70,7 @@ SRC_URI = "\
file://0053-gcc-fix-segfault-from-calling-free-on-non-malloc-d-a.patch 
\

file://0054-gcc-Makefile.in-fix-parallel-building-failure.patch \
file://0055-PR-rtl-optimization-61801.patch \
+ file://0056-redefine-dynamic-linker-for-aarch64.patch \
"
SRC_URI[md5sum] = "fddf71348546af523353bd43d34919c1"
SRC_URI[sha256sum] = 
"d334781a124ada6f38e63b545e2a3b8c2183049515a1abab6d513f109f1d717e"
diff --git 
a/meta/recipes-devtools/gcc/gcc-4.9/0056-redefine-dynamic-linker-for-aarch64.patch 
b/meta/recipes-devtools/gcc/gcc-4.9/0056-redefine-dynamic-linker-for-aarch64.patch 


new file mode 100644
index 000..6933e2f
--- /dev/null
+++ 
b/meta/recipes-devtools/gcc/gcc-4.9/0056-redefine-dynamic-linker-for-aarch64.patch

@@ -0,0 +1,34 @@
+From 8fbb60d89e569b68b13e4fd419e20640eb49cabc Mon Sep 17 00:00:00 
2001

+From: Kai Kang 
+Date: Tue, 16 Sep 2014 16:01:31 +0800
+Subject: [PATCH] Redefine dynamic linker for aarch64
+
+Redefine dynamic linker for aarch64 from /lib to /lib64.
+
+BASELIB of aarch64 has to be defined with 'lib64', then linker file
+ld-linux-aarch64.so.1 is installed into /lib64 rather than /lib. So
+update it here too.
+
+Upstream-Status: Pending
+
+Signed-off-by: Kai Kang 
+---
+ gcc/config/aarch64/aarch64-linux.h | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/gcc/config/aarch64/aarch64-linux.h 
b/gcc/config/aarch64/aarch64-linux.h

+index a8f0771..2a6f06d 100644
+--- a/gcc/config/aarch64/aarch64-linux.h
 b/gcc/config/aarch64/aarch64-linux.h
+@@ -21,7 +21,7 @@
+ #ifndef GCC_AARCH64_LINUX_H
+ #define GCC_AARCH64_LINUX_H
+
+-#define GLIBC_DYNAMIC_LINKER 
"/lib/ld-linux-aarch64%{mbig-endian:_be}.so.1"
++#define GLIBC_DYNAMIC_LINKER 
"/lib64/ld-linux-aarch64%{mbig-endian:_be}.so.1"

+
+ #define CPP_SPEC "%{pthread:-D_REENTRANT}"
+
+--
+1.9.1
+



- -- 
- -Khem

-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
Comment: GPGTools - https://gpgtools.org

iEYEARECAAYFAlQah2UACgkQuwUzVZGdMxT98wCghPbcAP/2xFgFn9Lv3Wisexa6
kHkAni6hykOqPq44VheOimbMbcimHaZD
=jpy6
-END PGP SIGNATURE-








--
Regards,
Neil | Kai Kang

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

Re: [OE-core] [PATCH] sysklogd: set INHIBIT_UPDATERCD_BBCLASS if 'sysvinit' not in DISTRO_FEATURES

2014-09-18 Thread ChenQi


On 09/19/2014 12:06 PM, Fahad Usman wrote:

We need to set INHIBIT_UPDATERCD_BBCLASS to "1" if 'sysvinit' is not
present in DISTRO_FEATURES so that any un-necessary package dependencies
are not added by update-rc.d.bbclass

Signed-off-by: Fahad Usman 
---
  meta/recipes-extended/sysklogd/sysklogd.inc |5 +
  1 file changed, 5 insertions(+)

diff --git a/meta/recipes-extended/sysklogd/sysklogd.inc 
b/meta/recipes-extended/sysklogd/sysklogd.inc
index bcf8aa7..3cbbdfd 100644
--- a/meta/recipes-extended/sysklogd/sysklogd.inc
+++ b/meta/recipes-extended/sysklogd/sysklogd.inc
@@ -56,3 +56,8 @@ pkg_prerm_${PN} () {
fi
fi
  }
+
+python __anonymous() {
+if not bb.utils.contains('DISTRO_FEATURES', 'sysvinit', True, False, d):
+d.setVar("INHIBIT_UPDATERCD_BBCLASS", "1")
+}


I'm now adding systemd support for sysklogd.
This recipe will then inherit systemd.bbclass.
And the task of setting INHIBIT_UPDATERCD_BBCLASS is automatically done.

The patches will be sent out in one day or two.

Best Regards,
Chen Qi
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH v2 6/8] blktrace: obey LDFLAGS for btrecord

On Thu, Sep 18, 2014 at 1:51 PM, Christopher Larson  wrote:
>
> On Thu, Sep 18, 2014 at 12:26 AM, Khem Raj  wrote:
>>
>> On 9/16/14 6:17 PM, Christopher Larson wrote:
>> > From: Christopher Larson 
>> >
>> > Signed-off-by: Christopher Larson 
>> > ---
>> >  meta/recipes-kernel/blktrace/blktrace/ldflags.patch | 8 ++--
>> >  1 file changed, 6 insertions(+), 2 deletions(-)
>> >
>> > diff --git a/meta/recipes-kernel/blktrace/blktrace/ldflags.patch
>> > b/meta/recipes-kernel/blktrace/blktrace/ldflags.patch
>> > index b9c7c20..037d161 100644
>> > --- a/meta/recipes-kernel/blktrace/blktrace/ldflags.patch
>> > +++ b/meta/recipes-kernel/blktrace/blktrace/ldflags.patch
>> > @@ -59,8 +59,12 @@ Signed-off-by: Fahad Usman 
>> >   INCS= -I. -I.. -I../btt
>> >   OCFLAGS = -UCOUNT_IOS -UDEBUG -DNDEBUG
>> >   XCFLAGS = -D_GNU_SOURCE -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
>> > -@@ -35,7 +36,7 @@ btrecord: btrecord.o
>> > - $(CC) $(CFLAGS) -o $@ $(filter %.o,$^)
>> > +@@ -32,10 +33,10 @@ clean: docsclean
>> > + $(CC) $(CFLAGS) -c -o $*.o $<
>> > +
>> > + btrecord: btrecord.o
>> > +-$(CC) $(CFLAGS) -o $@ $(filter %.o,$^)
>> > ++$(CC) $(CFLAGS) -o $@ $(filter %.o,$^) $(LDFLAGS)
>> >
>>
>> aren't you passing LDFLAGS to compile step as well here ?
>
>
> I don't think so. This rule creates btrecord from btrecord.o, it doesn't
> compile btrecord.c to btrecord.o, that's an entirely different rule.

thats right. I confused it with filter
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] sysklogd: set INHIBIT_UPDATERCD_BBCLASS if 'sysvinit' not in DISTRO_FEATURES

2014-09-18 Thread Fahad Usman

We need to set INHIBIT_UPDATERCD_BBCLASS to "1" if 'sysvinit' is not
present in DISTRO_FEATURES so that any un-necessary package dependencies
are not added by update-rc.d.bbclass

Signed-off-by: Fahad Usman 
---
 meta/recipes-extended/sysklogd/sysklogd.inc |5 +
 1 file changed, 5 insertions(+)

diff --git a/meta/recipes-extended/sysklogd/sysklogd.inc 
b/meta/recipes-extended/sysklogd/sysklogd.inc
index bcf8aa7..3cbbdfd 100644
--- a/meta/recipes-extended/sysklogd/sysklogd.inc
+++ b/meta/recipes-extended/sysklogd/sysklogd.inc
@@ -56,3 +56,8 @@ pkg_prerm_${PN} () {
fi
fi
 }
+
+python __anonymous() {
+if not bb.utils.contains('DISTRO_FEATURES', 'sysvinit', True, False, d):
+d.setVar("INHIBIT_UPDATERCD_BBCLASS", "1")
+}
-- 
1.7.9.5

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

[OE-core] [PATCH] ltp: Added zip-native as a DEPENDS

2014-09-18 Thread Hernandez

From: Alejandro Hernandez 

The Makefile checks for zip during installation

[YOCTO #6699]

Signed-off-by: Alejandro Hernandez 
---
 meta/recipes-extended/ltp/ltp_20140422.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-extended/ltp/ltp_20140422.bb 
b/meta/recipes-extended/ltp/ltp_20140422.bb
index c658bc0..f2c0fd8 100644
--- a/meta/recipes-extended/ltp/ltp_20140422.bb
+++ b/meta/recipes-extended/ltp/ltp_20140422.bb
@@ -19,7 +19,7 @@ LIC_FILES_CHKSUM = "\
 file://utils/ffsb-6.0-rc2/COPYING;md5=c46082167a314d785d012a244748d803 \
 "
 
-DEPENDS = "attr libaio libcap acl openssl"
+DEPENDS = "attr libaio libcap acl openssl zip-native"
 SRCREV = "f4c3bfe1eab51eb72caeb0f3336d2790c9a8bd1b"
 
 SRC_URI = "git://github.com/linux-test-project/ltp.git \
-- 
1.9.1

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

Re: [OE-core] [PATCH v2 6/8] blktrace: obey LDFLAGS for btrecord

2014-09-18 Thread Christopher Larson

On Thu, Sep 18, 2014 at 12:26 AM, Khem Raj  wrote:

> On 9/16/14 6:17 PM, Christopher Larson wrote:
> > From: Christopher Larson 
> >
> > Signed-off-by: Christopher Larson 
> > ---
> >  meta/recipes-kernel/blktrace/blktrace/ldflags.patch | 8 ++--
> >  1 file changed, 6 insertions(+), 2 deletions(-)
> >
> > diff --git a/meta/recipes-kernel/blktrace/blktrace/ldflags.patch
> b/meta/recipes-kernel/blktrace/blktrace/ldflags.patch
> > index b9c7c20..037d161 100644
> > --- a/meta/recipes-kernel/blktrace/blktrace/ldflags.patch
> > +++ b/meta/recipes-kernel/blktrace/blktrace/ldflags.patch
> > @@ -59,8 +59,12 @@ Signed-off-by: Fahad Usman 
> >   INCS= -I. -I.. -I../btt
> >   OCFLAGS = -UCOUNT_IOS -UDEBUG -DNDEBUG
> >   XCFLAGS = -D_GNU_SOURCE -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
> > -@@ -35,7 +36,7 @@ btrecord: btrecord.o
> > - $(CC) $(CFLAGS) -o $@ $(filter %.o,$^)
> > +@@ -32,10 +33,10 @@ clean: docsclean
> > + $(CC) $(CFLAGS) -c -o $*.o $<
> > +
> > + btrecord: btrecord.o
> > +-$(CC) $(CFLAGS) -o $@ $(filter %.o,$^)
> > ++$(CC) $(CFLAGS) -o $@ $(filter %.o,$^) $(LDFLAGS)
> >
>
> aren't you passing LDFLAGS to compile step as well here ?


I don't think so. This rule creates btrecord from btrecord.o, it doesn't
compile btrecord.c to btrecord.o, that's an entirely different rule.
-- 
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 1/3] sstatesig: Only dump incremental locked signatures


On 09/18/2014 09:47 PM, Richard Purdie wrote:

I'm afraid I'm starting to feel very strongly this is not a direction we
should move in. Having the ability to write out a .inc file containing
on a delta is one thing, writing out a file for automatic inclusion and
trying to maintain that file is not something I feel comfortable with.

I think that at some point there needs to be external tooling handling
the inclusion and updating of this file and that the sigs code is not
the place for this.

For example, consider the case where you switch machines and want to
share an include file between these machines. With the changes proposed
in this patch series it will simply overwrite the file and remove the
entries for the other machine.


Yes, you are right, it will overwrite, not for the locked sig file,
but the core structure self.lockedsigs

It could explain the necessary why I add 'type' to self.lockedsigs
in previous path series.
{pn:{task:{hash}}} --> {type:{pn:{task:{hash

//Hongxu



We could keep trying to patch up this code to cover every combination
and eventuality but in the end, I believe the maintenance of this file
should be something external, the sigs code should only be concerned
with the generation of the core entries.

Cheers,

Richard


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

Re: [OE-core] [PATCH 1/1] dhcp: set Type=forking for dhcpd.service

2014-09-18 Thread Randy Witt


On 09/17/2014 10:50 PM, Chen Qi wrote:

Set Type=forking for dhcpd.service to make it start up correctly.

Signed-off-by: Chen Qi 
---
  meta/recipes-connectivity/dhcp/files/dhcpd.service | 1 +
  1 file changed, 1 insertion(+)

diff --git a/meta/recipes-connectivity/dhcp/files/dhcpd.service 
b/meta/recipes-connectivity/dhcp/files/dhcpd.service
index 8648f1a..80f6c41 100644
--- a/meta/recipes-connectivity/dhcp/files/dhcpd.service
+++ b/meta/recipes-connectivity/dhcp/files/dhcpd.service
@@ -4,6 +4,7 @@ After=network.target
  After=time-sync.target

  [Service]
+Type=forking


Is it possible to set "PIDFile=" as well? There can be some weird 
behaviour if systemd loses track of the child process.



  EnvironmentFile=@SYSCONFDIR@/default/dhcp-server
  ExecStart=-@SBINDIR@/dhcpd -q $INTERFACES




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

[OE-core] [PATCH 1/2] linux-yocto/3.10: update to v3.10.54 and -rt55

2014-09-18 Thread Bruce Ashfield

The 3.10 kernel needed a refresh to the latest -stable and -rt releases.

Signed-off-by: Bruce Ashfield 
---
 meta/recipes-kernel/linux/linux-yocto-rt_3.10.bb   |  8 
 meta/recipes-kernel/linux/linux-yocto-tiny_3.10.bb |  6 +++---
 meta/recipes-kernel/linux/linux-yocto_3.10.bb  | 18 +-
 3 files changed, 16 insertions(+), 16 deletions(-)

diff --git a/meta/recipes-kernel/linux/linux-yocto-rt_3.10.bb 
b/meta/recipes-kernel/linux/linux-yocto-rt_3.10.bb
index 2f22ba8ea690..b08d7c34c324 100644
--- a/meta/recipes-kernel/linux/linux-yocto-rt_3.10.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-rt_3.10.bb
@@ -3,13 +3,13 @@ KBRANCH_qemuppc ?= "standard/preempt-rt/qemuppc"
 
 require recipes-kernel/linux/linux-yocto.inc
 
-SRCREV_machine ?= "1dfc94848e05989ab6c5fde2080f35546d81e798"
-SRCREV_machine_qemuppc ?= "81334ed6f11da157e13c306c48f3d49a051d9d89"
-SRCREV_meta ?= "fab23a4d44de25ee77e497cbf8605eadc3aaf3d8"
+SRCREV_machine ?= "74d7df0601f4879b525a0f2a0a187c33a23be580"
+SRCREV_machine_qemuppc ?= "087f9fff0860e9a357fe9d4b1f514031e2c2597b"
+SRCREV_meta ?= "5ea3fd0817c2a3173e85102c61c51a5a6268cad6"
 
 SRC_URI = 
"git://git.yoctoproject.org/linux-yocto-3.10.git;bareclone=1;branch=${KBRANCH},meta;name=machine,meta"
 
-LINUX_VERSION ?= "3.10.43"
+LINUX_VERSION ?= "3.10.54"
 
 PV = "${LINUX_VERSION}+git${SRCPV}"
 
diff --git a/meta/recipes-kernel/linux/linux-yocto-tiny_3.10.bb 
b/meta/recipes-kernel/linux/linux-yocto-tiny_3.10.bb
index bd762f9fff29..6885723977e8 100644
--- a/meta/recipes-kernel/linux/linux-yocto-tiny_3.10.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-tiny_3.10.bb
@@ -5,12 +5,12 @@ require recipes-kernel/linux/linux-yocto.inc
 LINUX_KERNEL_TYPE = "tiny"
 KCONFIG_MODE = "--allnoconfig"
 
-LINUX_VERSION ?= "3.10.43"
+LINUX_VERSION ?= "3.10.54"
 
 KMETA = "meta"
 
-SRCREV_machine ?= "e4f08d724d6663e6d23d19668c97f9e6792c94d2"
-SRCREV_meta ?= "fab23a4d44de25ee77e497cbf8605eadc3aaf3d8"
+SRCREV_machine ?= "e001d3cbec5320c03d2a316aa0e287012be19133"
+SRCREV_meta ?= "5ea3fd0817c2a3173e85102c61c51a5a6268cad6"
 
 PV = "${LINUX_VERSION}+git${SRCPV}"
 
diff --git a/meta/recipes-kernel/linux/linux-yocto_3.10.bb 
b/meta/recipes-kernel/linux/linux-yocto_3.10.bb
index 298d2ca79923..3cb8c582578d 100644
--- a/meta/recipes-kernel/linux/linux-yocto_3.10.bb
+++ b/meta/recipes-kernel/linux/linux-yocto_3.10.bb
@@ -10,18 +10,18 @@ KBRANCH_qemux86  ?= "standard/common-pc/base"
 KBRANCH_qemux86-64  ?= "standard/common-pc-64/base"
 KBRANCH_qemumips64 ?= "standard/mti-malta64"
 
-SRCREV_machine_qemuarm ?= "cf951fb02f9eb89bd36f30fd6d426d6a06be8739"
-SRCREV_machine_qemumips ?= "82c743bcc8103c82f8cb673eb810a9329a9441d7"
-SRCREV_machine_qemuppc ?= "1deb0e97e9262b02b3ff9b707b13c42c8fa95a13"
-SRCREV_machine_qemux86 ?= "e4f08d724d6663e6d23d19668c97f9e6792c94d2"
-SRCREV_machine_qemux86-64 ?= "e4f08d724d6663e6d23d19668c97f9e6792c94d2"
-SRCREV_machine_qemumips64 ?= "8affc1996043dfe2061953c074c714a9885fde6e"
-SRCREV_machine ?= "e4f08d724d6663e6d23d19668c97f9e6792c94d2"
-SRCREV_meta ?= "fab23a4d44de25ee77e497cbf8605eadc3aaf3d8"
+SRCREV_machine_qemuarm ?= "f075141532317cb7f8b88843354cd901c18c13a1"
+SRCREV_machine_qemumips ?= "e7582bdb55376801e9749141af9f1cc0a9425a31"
+SRCREV_machine_qemuppc ?= "fdc57cf78d788a5efc44ffaafa09db1a3799e5f0"
+SRCREV_machine_qemux86 ?= "e001d3cbec5320c03d2a316aa0e287012be19133"
+SRCREV_machine_qemux86-64 ?= "e001d3cbec5320c03d2a316aa0e287012be19133"
+SRCREV_machine_qemumips64 ?= "e8fdd57656858f06547f61336e130d006fc88de5"
+SRCREV_machine ?= "e001d3cbec5320c03d2a316aa0e287012be19133"
+SRCREV_meta ?= "5ea3fd0817c2a3173e85102c61c51a5a6268cad6"
 
 SRC_URI = 
"git://git.yoctoproject.org/linux-yocto-3.10.git;bareclone=1;branch=${KBRANCH},${KMETA};name=machine,meta"
 
-LINUX_VERSION ?= "3.10.43"
+LINUX_VERSION ?= "3.10.54"
 
 PV = "${LINUX_VERSION}+git${SRCPV}"
 
-- 
1.8.1.2

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

[OE-core] [PATCH 2/2] linux-yocto/3.14: update to v3.14.18 and -rt9

2014-09-18 Thread Bruce Ashfield

Refreshing the 3.14 kernel to a new korg stable and -rt release.

Signed-off-by: Bruce Ashfield 
---
 meta/recipes-kernel/linux/linux-yocto-rt_3.14.bb   |  8 
 meta/recipes-kernel/linux/linux-yocto-tiny_3.14.bb |  6 +++---
 meta/recipes-kernel/linux/linux-yocto_3.14.bb  | 18 +-
 3 files changed, 16 insertions(+), 16 deletions(-)

diff --git a/meta/recipes-kernel/linux/linux-yocto-rt_3.14.bb 
b/meta/recipes-kernel/linux/linux-yocto-rt_3.14.bb
index 1d69fc687bde..0977b6275c6e 100644
--- a/meta/recipes-kernel/linux/linux-yocto-rt_3.14.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-rt_3.14.bb
@@ -3,13 +3,13 @@ KBRANCH_qemuppc ?= "standard/preempt-rt/qemuppc"
 
 require recipes-kernel/linux/linux-yocto.inc
 
-SRCREV_machine ?= "cf214eea750707e6261818837e5c508ac1299b19"
-SRCREV_machine_qemuppc ?= "3d5a421fc5c171cd5d322b092e78e0e0dd4f340e"
-SRCREV_meta ?= "a94680bfeb0e8e3025b57f8b42d0825ba743376b"
+SRCREV_machine ?= "41975d7825d8043b054378565b01824ffa961834"
+SRCREV_machine_qemuppc ?= "3bbc23a726520784618a3854747b82792d2a108f"
+SRCREV_meta ?= "80c78725e098d26b9464c4d5cffd37c28f42dc7b"
 
 SRC_URI = 
"git://git.yoctoproject.org/linux-yocto-3.14.git;bareclone=1;branch=${KBRANCH},meta;name=machine,meta"
 
-LINUX_VERSION ?= "3.14.17"
+LINUX_VERSION ?= "3.14.18"
 
 PV = "${LINUX_VERSION}+git${SRCPV}"
 
diff --git a/meta/recipes-kernel/linux/linux-yocto-tiny_3.14.bb 
b/meta/recipes-kernel/linux/linux-yocto-tiny_3.14.bb
index 9f78951c52bf..4eb7b1dd477d 100644
--- a/meta/recipes-kernel/linux/linux-yocto-tiny_3.14.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-tiny_3.14.bb
@@ -4,12 +4,12 @@ KCONFIG_MODE = "--allnoconfig"
 
 require recipes-kernel/linux/linux-yocto.inc
 
-LINUX_VERSION ?= "3.14.17"
+LINUX_VERSION ?= "3.14.18"
 
 KMETA = "meta"
 
-SRCREV_machine ?= "b85edae6fd61ceadfc08099608e8ac90aa4c5c33"
-SRCREV_meta ?= "a94680bfeb0e8e3025b57f8b42d0825ba743376b"
+SRCREV_machine ?= "fabce749eb25b8053250b5507868a246ddaf4423"
+SRCREV_meta ?= "80c78725e098d26b9464c4d5cffd37c28f42dc7b"
 
 PV = "${LINUX_VERSION}+git${SRCPV}"
 
diff --git a/meta/recipes-kernel/linux/linux-yocto_3.14.bb 
b/meta/recipes-kernel/linux/linux-yocto_3.14.bb
index e06b191673e3..6eac062d5964 100644
--- a/meta/recipes-kernel/linux/linux-yocto_3.14.bb
+++ b/meta/recipes-kernel/linux/linux-yocto_3.14.bb
@@ -10,18 +10,18 @@ KBRANCH_qemux86  ?= "standard/common-pc/base"
 KBRANCH_qemux86-64 ?= "standard/common-pc-64/base"
 KBRANCH_qemumips64 ?= "standard/mti-malta64"
 
-SRCREV_machine_qemuarm ?= "c32a2e1190325f685a61196f38fc03ceff2645bf"
-SRCREV_machine_qemumips ?= "1ff50c529b49ceb55a670258f7cb8233c8006c6c"
-SRCREV_machine_qemuppc ?= "12e9828a5b78891374375233b4075f682b9fbd0e"
-SRCREV_machine_qemux86 ?= "58d49fe770ad642e2bc0616159195ba837dc513b"
-SRCREV_machine_qemux86-64 ?= "b85edae6fd61ceadfc08099608e8ac90aa4c5c33"
-SRCREV_machine_qemumips64 ?= "dcd579737386fca4d7bcf224bc118b14eb3c1d55"
-SRCREV_machine ?= "b85edae6fd61ceadfc08099608e8ac90aa4c5c33"
-SRCREV_meta ?= "a94680bfeb0e8e3025b57f8b42d0825ba743376b"
+SRCREV_machine_qemuarm ?= "3d5be74be2cab047a1b85e07620beee4791d4594"
+SRCREV_machine_qemumips ?= "2834013809154887772cf1552191a682ed42d9eb"
+SRCREV_machine_qemuppc ?= "44dddef534a3cae1aa952f77f4fd299978552307"
+SRCREV_machine_qemux86 ?= "d77fb23dcc717061f74678babaeb4fa487c55fec"
+SRCREV_machine_qemux86-64 ?= "fabce749eb25b8053250b5507868a246ddaf4423"
+SRCREV_machine_qemumips64 ?= "5c5d8fd23d2b8fb0e8e00e54d2783feeba86ebd0"
+SRCREV_machine ?= "fabce749eb25b8053250b5507868a246ddaf4423"
+SRCREV_meta ?= "80c78725e098d26b9464c4d5cffd37c28f42dc7b"
 
 SRC_URI = 
"git://git.yoctoproject.org/linux-yocto-3.14.git;bareclone=1;branch=${KBRANCH},${KMETA};name=machine,meta"
 
-LINUX_VERSION ?= "3.14.17"
+LINUX_VERSION ?= "3.14.18"
 
 PV = "${LINUX_VERSION}+git${SRCPV}"
 
-- 
1.8.1.2

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

[OE-core] [PATCH 0/2] linux-yocto/3.10/3.14: SRCREV updates

2014-09-18 Thread Bruce Ashfield

Hi all,

Here are the final -stable refresh update for 3.10 and 3.14 for the 1.7
release.

I've done build and boot testing for the arches on qemu machines, both for
standard and -rt. That being said, feeding it to a round of automated build
testing would be ideal, since I can't cover every single config and case.

I'll follow up with h/w reference board updates, which are staying on 
3.14 for this release, so they need the new SRCREVs as well.

Cheers,

Bruce

The following changes since commit 280b6d0011f101e7a8edabd34c265b37a2f791ed:

  sstatesig: fix overrides behaviour to remove SIGGEN_LOCKEDSIGS_i586 
(2014-09-17 22:00:26 +0100)

are available in the git repository at:

  git://git.pokylinux.org/poky-contrib zedd/kernel
  http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=zedd/kernel

Bruce Ashfield (2):
  linux-yocto/3.10: update to v3.10.54 and -rt55
  linux-yocto/3.14: update to v3.14.18 and -rt9

 meta/recipes-kernel/linux/linux-yocto-rt_3.10.bb   |  8 
 meta/recipes-kernel/linux/linux-yocto-rt_3.14.bb   |  8 
 meta/recipes-kernel/linux/linux-yocto-tiny_3.10.bb |  6 +++---
 meta/recipes-kernel/linux/linux-yocto-tiny_3.14.bb |  6 +++---
 meta/recipes-kernel/linux/linux-yocto_3.10.bb  | 18 +-
 meta/recipes-kernel/linux/linux-yocto_3.14.bb  | 18 +-
 6 files changed, 32 insertions(+), 32 deletions(-)

-- 
1.8.1.2

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

[OE-core] [PATCH] systemd: disable resolv.conf symlink unless resolved is enabled

2014-09-18 Thread Peter A. Bigot

The tmpfiles configuration in systemd unconditionally creates a symlink
from /etc/resolv.conf to the location where systemd's resolved service
will place the real file.  This link is only appropriate when resolved
is enabled and running: its presence prevents connman or other systems
from providing a working resolv.conf when systemd is not assigned that
responsibility.  OE has not yet enabled systemd's networkd or resolved
by default.

There is a TODO in the systemd source to fix this, but it has not been
addressed upstream.  This patch comments out the corresponding line when
resolved is not enabled in the package configuration.

Signed-off-by: Peter A. Bigot 
---
 ...es.d-etc.conf-disable-resolv.conf-symlink.patch | 35 ++
 meta/recipes-core/systemd/systemd_216.bb   |  1 +
 2 files changed, 36 insertions(+)
 create mode 100644 
meta/recipes-core/systemd/systemd/0001-tmpfiles.d-etc.conf-disable-resolv.conf-symlink.patch

diff --git 
a/meta/recipes-core/systemd/systemd/0001-tmpfiles.d-etc.conf-disable-resolv.conf-symlink.patch
 
b/meta/recipes-core/systemd/systemd/0001-tmpfiles.d-etc.conf-disable-resolv.conf-symlink.patch
new file mode 100644
index 000..7218322
--- /dev/null
+++ 
b/meta/recipes-core/systemd/systemd/0001-tmpfiles.d-etc.conf-disable-resolv.conf-symlink.patch
@@ -0,0 +1,35 @@
+From f0ab1600fb56d680e6aba3d0d51dfb9ffa3d9403 Mon Sep 17 00:00:00 2001
+From: "Peter A. Bigot" 
+Date: Thu, 18 Sep 2014 08:36:54 -0500
+Subject: [PATCH] tmpfiles.d/etc.conf: disable resolv.conf symlink
+
+This link is valid only if ENABLE_RESOLVED is configured for systemd.
+If left unconditional, the symlink is created preventing connman from
+storing the configuration it received from DHCP or other sources.
+
+Upstream has a TODO to fix this, but has not done so as of this date.
+Provide a temporary workaround for OE until this is done properly
+upstream.
+
+Upstream-Status: Inappropriate [OE-specific]
+Signed-off-by: Peter A. Bigot 
+---
+ tmpfiles.d/etc.conf | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+diff --git a/tmpfiles.d/etc.conf b/tmpfiles.d/etc.conf
+index b23272c..5364dd8 100644
+--- a/tmpfiles.d/etc.conf
 b/tmpfiles.d/etc.conf
+@@ -10,6 +10,7 @@
+ L /etc/os-release - - - - ../usr/lib/os-release
+ L /etc/localtime - - - - ../usr/share/zoneinfo/UTC
+ L+ /etc/mtab - - - - ../proc/self/mounts
+-L /etc/resolv.conf - - - - ../run/systemd/resolve/resolv.conf
++# TODO: conditional on ENABLE_RESOLVED
++#L /etc/resolv.conf - - - - ../run/systemd/resolve/resolv.conf
+ C /etc/nsswitch.conf - - - -
+ C /etc/pam.d - - - -
+-- 
+1.8.5.5
+
diff --git a/meta/recipes-core/systemd/systemd_216.bb 
b/meta/recipes-core/systemd/systemd_216.bb
index 331da99..ebf9395 100644
--- a/meta/recipes-core/systemd/systemd_216.bb
+++ b/meta/recipes-core/systemd/systemd_216.bb
@@ -36,6 +36,7 @@ SRC_URI = 
"git://anongit.freedesktop.org/systemd/systemd;branch=master;protocol=
file://00-create-volatile.conf \
file://init \
file://run-ptest \
+   ${@bb.utils.contains('PACKAGECONFIG', 'resolved', '', 
'file://0001-tmpfiles.d-etc.conf-disable-resolv.conf-symlink.patch', d)} \
   "
 
 S = "${WORKDIR}/git"
-- 
1.8.5.5

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

Re: [OE-core] [PATCH 1/3] sstatesig: Only dump incremental locked signatures

On 09/18/2014 09:47 PM, Richard Purdie wrote:

I'm afraid I'm starting to feel very strongly this is not a direction we
should move in. Having the ability to write out a .inc file containing
on a delta is one thing, writing out a file for automatic inclusion and
trying to maintain that file is not something I feel comfortable with.

Yes, I understand that your worry is reasonable, so many unexpected
exception needs to be maintained

I think that at some point there needs to be external tooling handling
the inclusion and updating of this file and that the sigs code is not
the place for this.

I once coded a python script to handling the locked sig file from an
existed sstate, translated sstate item name (ends with '.tgz.siginfo')
to "::" tuple.

The main blocker is: for some tasks (such as do_patch/do_fetch/
do_unpack), the target and native have the same pn in sstate, such as:
''sstate-cache/c6/sstate:automake::1.14.1:r0::3:c667b87f5d4e15198afc744f525895fc_unpack.tgz.siginfo"
is used for "automake" and "automake-native", you could not figure
out arch (which used as type in locked sig file) from it neither.

For example, consider the case where you switch machines and want to
share an include file between these machines. With the changes proposed
in this patch series it will simply overwrite the file and remove the
entries for the other machine.

I think the swith machines case could work in this patch series,
It appends to the tail of the locked sig file, and not overwrite
the other machine's sig if incremetnal dump is set.

But I indeed understand what you worry about.

We could keep trying to patch up this code to cover every combination
and eventuality but in the end, I believe the maintenance of this file
should be something external, the sigs code should only be concerned
with the generation of the core entries.

Completely agree.

//Hongxu

Cheers,

Richard

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

Re: [OE-core] [PATCH 3/9] gcc-4.9: redefine dynamic linker for aarch64

2014-09-18 Thread Mark Hatle


On 9/18/14, 8:58 AM, Mark Hatle wrote:

On 9/18/14, 2:19 AM, Khem Raj wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1



On 9/16/14 8:06 AM, Kai Kang wrote:

Redefine dynamic linker for aarch64 from /lib to /lib64.

BASELIB of aarch64 has to be defined with 'lib64', then linker file
ld-linux-aarch64.so.1 is installed into /lib64 rather than /lib. So
update it here too.


hmmm since the ldso name is different it can still live in /lib
and there will be ilp32 version ldso multilib as well later. can we keep
ldso in /lib ?


I thought the upstream definition (managed by ARM Ltd, and Linaro) for the ld.so
had changed a few months back so that /lib64 was the 'standard' location for the
ldso.  Perhaps I'm mistaken?


I did some research and I'm confused.. aarch64 is screwed up by consensus 
apparently..


Dynamic libraries live in /lib64, and the dynamic linker in /lib.. Whee!

So ya, this patch isn't correct.. the dynamic linker needs to stay in /lib. 
(Nothing says you can't sym/hardlink to lib64.. but it has to refer to in in 
/lib for the ABI conformance.)


--Mark


--Mark



Signed-off-by: Kai Kang 
---
   meta/recipes-devtools/gcc/gcc-4.9.inc  |  1 +
   .../0056-redefine-dynamic-linker-for-aarch64.patch | 34 
++
   2 files changed, 35 insertions(+)
   create mode 100644 
meta/recipes-devtools/gcc/gcc-4.9/0056-redefine-dynamic-linker-for-aarch64.patch

diff --git a/meta/recipes-devtools/gcc/gcc-4.9.inc 
b/meta/recipes-devtools/gcc/gcc-4.9.inc
index 25778bd..c434a45 100644
--- a/meta/recipes-devtools/gcc/gcc-4.9.inc
+++ b/meta/recipes-devtools/gcc/gcc-4.9.inc
@@ -70,6 +70,7 @@ SRC_URI = "\
   file://0053-gcc-fix-segfault-from-calling-free-on-non-malloc-d-a.patch \
   file://0054-gcc-Makefile.in-fix-parallel-building-failure.patch \
   file://0055-PR-rtl-optimization-61801.patch \
+file://0056-redefine-dynamic-linker-for-aarch64.patch \
   "
   SRC_URI[md5sum] = "fddf71348546af523353bd43d34919c1"
   SRC_URI[sha256sum] = 
"d334781a124ada6f38e63b545e2a3b8c2183049515a1abab6d513f109f1d717e"
diff --git 
a/meta/recipes-devtools/gcc/gcc-4.9/0056-redefine-dynamic-linker-for-aarch64.patch
 
b/meta/recipes-devtools/gcc/gcc-4.9/0056-redefine-dynamic-linker-for-aarch64.patch
new file mode 100644
index 000..6933e2f
--- /dev/null
+++ 
b/meta/recipes-devtools/gcc/gcc-4.9/0056-redefine-dynamic-linker-for-aarch64.patch
@@ -0,0 +1,34 @@
+From 8fbb60d89e569b68b13e4fd419e20640eb49cabc Mon Sep 17 00:00:00 2001
+From: Kai Kang 
+Date: Tue, 16 Sep 2014 16:01:31 +0800
+Subject: [PATCH] Redefine dynamic linker for aarch64
+
+Redefine dynamic linker for aarch64 from /lib to /lib64.
+
+BASELIB of aarch64 has to be defined with 'lib64', then linker file
+ld-linux-aarch64.so.1 is installed into /lib64 rather than /lib. So
+update it here too.
+
+Upstream-Status: Pending
+
+Signed-off-by: Kai Kang 
+---
+ gcc/config/aarch64/aarch64-linux.h | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/gcc/config/aarch64/aarch64-linux.h 
b/gcc/config/aarch64/aarch64-linux.h
+index a8f0771..2a6f06d 100644
+--- a/gcc/config/aarch64/aarch64-linux.h
 b/gcc/config/aarch64/aarch64-linux.h
+@@ -21,7 +21,7 @@
+ #ifndef GCC_AARCH64_LINUX_H
+ #define GCC_AARCH64_LINUX_H
+
+-#define GLIBC_DYNAMIC_LINKER "/lib/ld-linux-aarch64%{mbig-endian:_be}.so.1"
++#define GLIBC_DYNAMIC_LINKER "/lib64/ld-linux-aarch64%{mbig-endian:_be}.so.1"
+
+ #define CPP_SPEC "%{pthread:-D_REENTRANT}"
+
+--
+1.9.1
+



- --
- -Khem
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
Comment: GPGTools - https://gpgtools.org

iEYEARECAAYFAlQah2UACgkQuwUzVZGdMxT98wCghPbcAP/2xFgFn9Lv3Wisexa6
kHkAni6hykOqPq44VheOimbMbcimHaZD
=jpy6
-END PGP SIGNATURE-





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

Re: [OE-core] [PATCH 3/9] gcc-4.9: redefine dynamic linker for aarch64

2014-09-18 Thread Mark Hatle


On 9/18/14, 2:19 AM, Khem Raj wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1



On 9/16/14 8:06 AM, Kai Kang wrote:

Redefine dynamic linker for aarch64 from /lib to /lib64.

BASELIB of aarch64 has to be defined with 'lib64', then linker file
ld-linux-aarch64.so.1 is installed into /lib64 rather than /lib. So
update it here too.


hmmm since the ldso name is different it can still live in /lib
and there will be ilp32 version ldso multilib as well later. can we keep
ldso in /lib ?


I thought the upstream definition (managed by ARM Ltd, and Linaro) for the ld.so 
had changed a few months back so that /lib64 was the 'standard' location for the 
ldso.  Perhaps I'm mistaken?


--Mark



Signed-off-by: Kai Kang 
---
  meta/recipes-devtools/gcc/gcc-4.9.inc  |  1 +
  .../0056-redefine-dynamic-linker-for-aarch64.patch | 34 ++
  2 files changed, 35 insertions(+)
  create mode 100644 
meta/recipes-devtools/gcc/gcc-4.9/0056-redefine-dynamic-linker-for-aarch64.patch

diff --git a/meta/recipes-devtools/gcc/gcc-4.9.inc 
b/meta/recipes-devtools/gcc/gcc-4.9.inc
index 25778bd..c434a45 100644
--- a/meta/recipes-devtools/gcc/gcc-4.9.inc
+++ b/meta/recipes-devtools/gcc/gcc-4.9.inc
@@ -70,6 +70,7 @@ SRC_URI = "\
  file://0053-gcc-fix-segfault-from-calling-free-on-non-malloc-d-a.patch \
  file://0054-gcc-Makefile.in-fix-parallel-building-failure.patch \
  file://0055-PR-rtl-optimization-61801.patch \
+file://0056-redefine-dynamic-linker-for-aarch64.patch \
  "
  SRC_URI[md5sum] = "fddf71348546af523353bd43d34919c1"
  SRC_URI[sha256sum] = 
"d334781a124ada6f38e63b545e2a3b8c2183049515a1abab6d513f109f1d717e"
diff --git 
a/meta/recipes-devtools/gcc/gcc-4.9/0056-redefine-dynamic-linker-for-aarch64.patch
 
b/meta/recipes-devtools/gcc/gcc-4.9/0056-redefine-dynamic-linker-for-aarch64.patch
new file mode 100644
index 000..6933e2f
--- /dev/null
+++ 
b/meta/recipes-devtools/gcc/gcc-4.9/0056-redefine-dynamic-linker-for-aarch64.patch
@@ -0,0 +1,34 @@
+From 8fbb60d89e569b68b13e4fd419e20640eb49cabc Mon Sep 17 00:00:00 2001
+From: Kai Kang 
+Date: Tue, 16 Sep 2014 16:01:31 +0800
+Subject: [PATCH] Redefine dynamic linker for aarch64
+
+Redefine dynamic linker for aarch64 from /lib to /lib64.
+
+BASELIB of aarch64 has to be defined with 'lib64', then linker file
+ld-linux-aarch64.so.1 is installed into /lib64 rather than /lib. So
+update it here too.
+
+Upstream-Status: Pending
+
+Signed-off-by: Kai Kang 
+---
+ gcc/config/aarch64/aarch64-linux.h | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/gcc/config/aarch64/aarch64-linux.h 
b/gcc/config/aarch64/aarch64-linux.h
+index a8f0771..2a6f06d 100644
+--- a/gcc/config/aarch64/aarch64-linux.h
 b/gcc/config/aarch64/aarch64-linux.h
+@@ -21,7 +21,7 @@
+ #ifndef GCC_AARCH64_LINUX_H
+ #define GCC_AARCH64_LINUX_H
+
+-#define GLIBC_DYNAMIC_LINKER "/lib/ld-linux-aarch64%{mbig-endian:_be}.so.1"
++#define GLIBC_DYNAMIC_LINKER "/lib64/ld-linux-aarch64%{mbig-endian:_be}.so.1"
+
+ #define CPP_SPEC "%{pthread:-D_REENTRANT}"
+
+--
+1.9.1
+



- --
- -Khem
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
Comment: GPGTools - https://gpgtools.org

iEYEARECAAYFAlQah2UACgkQuwUzVZGdMxT98wCghPbcAP/2xFgFn9Lv3Wisexa6
kHkAni6hykOqPq44VheOimbMbcimHaZD
=jpy6
-END PGP SIGNATURE-



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

Re: [OE-core] [PATCH 1/3] sstatesig: Only dump incremental locked signatures

2014-09-18 Thread Mark Hatle


On 9/18/14, 8:47 AM, Richard Purdie wrote:

On Thu, 2014-09-18 at 15:23 +0800, Hongxu Jia wrote:

The idea of incremental sig is:

New sig file = Old sig file (if available) + New sig items in current build.

The condition of incremental locked signature dump is an existed locked sig
file is required and it is also the dump sig file.

Signed-off-by: Hongxu Jia 
---
  meta/lib/oe/sstatesig.py | 12 
  1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/meta/lib/oe/sstatesig.py b/meta/lib/oe/sstatesig.py
index af7617e..56fd953 100644
--- a/meta/lib/oe/sstatesig.py
+++ b/meta/lib/oe/sstatesig.py
@@ -151,19 +151,23 @@ class 
SignatureGeneratorOEBasicHash(bb.siggen.SignatureGeneratorBasicHash):
  types[t] = []
  types[t].append(k)

-with open(sigfile, "w") as f:
+with open(sigfile, "a") as f:
  for t in types:
-f.write('SIGGEN_LOCKEDSIGS_%s = "\\\n' % t)
+f.write('SIGGEN_LOCKEDSIGS_%s += "\\\n' % t)
  types[t].sort()
  sortedk = sorted(types[t], key=lambda k: 
self.lockedpnmap[k.rsplit(".",1)[0]])
  for k in sortedk:
  fn = k.rsplit(".",1)[0]
+pn = self.lockedpnmap[fn]
  task = k.rsplit(".",1)[1]
  if k not in self.taskhash:
  continue
-f.write("" + self.lockedpnmap[fn] + ":" + task + ":" + 
self.taskhash[k] + " \\\n")
+if pn in self.lockedsigs and task in self.lockedsigs[pn] 
and self.taskhash[k] == self.lockedsigs[pn][task]:
+continue
+sigentry = pn + ":" + task + ":" + self.taskhash[k]
+f.write("" + sigentry + " \\\n")
  f.write('"\n')
-f.write('SIGGEN_LOCKEDSIGS_TYPES_%s = "%s"' % (self.machine, " 
".join(types.keys(
+f.write('SIGGEN_LOCKEDSIGS_TYPES_%s += "%s"\n' % (self.machine, " 
".join(types.keys(

  def checkhashes(self, missed, ret, sq_fn, sq_task, sq_hash, sq_hashfn, d):
  checklevel = d.getVar("SIGGEN_LOCKEDSIGS_CHECK_LEVEL", True)


I'm afraid I'm starting to feel very strongly this is not a direction we
should move in. Having the ability to write out a .inc file containing
on a delta is one thing, writing out a file for automatic inclusion and
trying to maintain that file is not something I feel comfortable with.

I think that at some point there needs to be external tooling handling
the inclusion and updating of this file and that the sigs code is not
the place for this.

For example, consider the case where you switch machines and want to
share an include file between these machines. With the changes proposed
in this patch series it will simply overwrite the file and remove the
entries for the other machine.

We could keep trying to patch up this code to cover every combination
and eventuality but in the end, I believe the maintenance of this file
should be something external, the sigs code should only be concerned
with the generation of the core entries.


This is why I was originally advocating a whitelist/blacklist approach with the 
read-only [or warn/error] sstate-cache approach.  It really is different then 
the locked signature.


The users want to use what they have that match the generated hashes, or get a 
warning/error -- unless the item is whitelisted.


They only need to manage a small list of the "things they changed" to support 
the white listing, and no complicated hashes are needed.


--Mark


Cheers,

Richard






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

Re: [OE-core] [PATCH 1/3] sstatesig: Only dump incremental locked signatures

2014-09-18 Thread Richard Purdie

On Thu, 2014-09-18 at 15:23 +0800, Hongxu Jia wrote:
> The idea of incremental sig is:
> 
> New sig file = Old sig file (if available) + New sig items in current build.
> 
> The condition of incremental locked signature dump is an existed locked sig
> file is required and it is also the dump sig file.
> 
> Signed-off-by: Hongxu Jia 
> ---
>  meta/lib/oe/sstatesig.py | 12 
>  1 file changed, 8 insertions(+), 4 deletions(-)
> 
> diff --git a/meta/lib/oe/sstatesig.py b/meta/lib/oe/sstatesig.py
> index af7617e..56fd953 100644
> --- a/meta/lib/oe/sstatesig.py
> +++ b/meta/lib/oe/sstatesig.py
> @@ -151,19 +151,23 @@ class 
> SignatureGeneratorOEBasicHash(bb.siggen.SignatureGeneratorBasicHash):
>  types[t] = []
>  types[t].append(k)
>  
> -with open(sigfile, "w") as f:
> +with open(sigfile, "a") as f:
>  for t in types:
> -f.write('SIGGEN_LOCKEDSIGS_%s = "\\\n' % t)
> +f.write('SIGGEN_LOCKEDSIGS_%s += "\\\n' % t)
>  types[t].sort()
>  sortedk = sorted(types[t], key=lambda k: 
> self.lockedpnmap[k.rsplit(".",1)[0]])
>  for k in sortedk:
>  fn = k.rsplit(".",1)[0]
> +pn = self.lockedpnmap[fn]
>  task = k.rsplit(".",1)[1]
>  if k not in self.taskhash:
>  continue
> -f.write("" + self.lockedpnmap[fn] + ":" + task + ":" 
> + self.taskhash[k] + " \\\n")
> +if pn in self.lockedsigs and task in self.lockedsigs[pn] 
> and self.taskhash[k] == self.lockedsigs[pn][task]:
> +continue
> +sigentry = pn + ":" + task + ":" + self.taskhash[k]
> +f.write("" + sigentry + " \\\n")
>  f.write('"\n')
> -f.write('SIGGEN_LOCKEDSIGS_TYPES_%s = "%s"' % (self.machine, " 
> ".join(types.keys(
> +f.write('SIGGEN_LOCKEDSIGS_TYPES_%s += "%s"\n' % (self.machine, 
> " ".join(types.keys(
>  
>  def checkhashes(self, missed, ret, sq_fn, sq_task, sq_hash, sq_hashfn, 
> d):
>  checklevel = d.getVar("SIGGEN_LOCKEDSIGS_CHECK_LEVEL", True)

I'm afraid I'm starting to feel very strongly this is not a direction we
should move in. Having the ability to write out a .inc file containing
on a delta is one thing, writing out a file for automatic inclusion and
trying to maintain that file is not something I feel comfortable with.

I think that at some point there needs to be external tooling handling
the inclusion and updating of this file and that the sigs code is not
the place for this.

For example, consider the case where you switch machines and want to
share an include file between these machines. With the changes proposed
in this patch series it will simply overwrite the file and remove the
entries for the other machine.

We could keep trying to patch up this code to cover every combination
and eventuality but in the end, I believe the maintenance of this file
should be something external, the sigs code should only be concerned
with the generation of the core entries.

Cheers,

Richard 

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

Re: [OE-core] Should lsb rdepends on lsbinitscripts?

2014-09-18 Thread Mario Domenech Goulart

Hi,

On Fri, 22 Aug 2014 19:47:22 + Mario Domenech Goulart 
 wrote:

> The scripts installed by the lsb package (under /etc/core-lsb) source
> /etc/init.d/functions, but that file is not installed by lsb or by any
> of its dependencies, as far as I can see.
>
> /etc/init.d/functions is provided by the lsbinitscripts package.  Should
> it be in lsb's RDEPENDS?

Any comment on this issue?

Best wishes.
Mario
-- 
http://www.ossystems.com.br
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] Yocto: Install full set of python modules in Qt SDK toolchain

2014-09-18 Thread Richard Purdie

On Thu, 2014-09-18 at 11:29 +0100, Laszlo Papp wrote:
> On Thu, Sep 18, 2014 at 10:30 AM, Marek Vasut  wrote:
> > On Thursday, September 18, 2014 at 11:23:13 AM, Laszlo Papp wrote:
> >> On Thu, Sep 18, 2014 at 10:16 AM, Marek Vasut  wrote:
> >> > On Thursday, September 18, 2014 at 11:11:45 AM, Laszlo Papp wrote:
> >> >> Come on, Yocto maintainers, please...
> >> >>
> >> >> Mark sent this change relatively long ago, and it is still in "new"
> >> >> state, sadly. The current SDK shipped _breaks_ any third-party
> >> >> software that uses standard python with regards to the libraries and
> >> >> all that.
> >> >>
> >> >> This is is slightly frustrating. We also face the same issue. :(
> >> >
> >> > Thanks for the reminder, new version which should fix the issues with the
> >> > previous one is on the ML now. You're all on CC.
> >>
> >> I do not think this is an explicit Qt issue, and hence fixing on that
> >> layer sounds like a weird approach. It seems to be a generic python
> >> issue and so, I think it should be addressed in its core. I opened a
> >> new report for this:
> >>
> >> https://bugzilla.yoctoproject.org/show_bug.cgi?id=6735
> >
> > Then you probably want to add nativesdk-packagegroup-python class into the 
> > other
> > toolchain recipes as well . Or even better, into the base SDK toolchain 
> > class
> > (is there one?)
> 
> See, I do not understand why this "feature" was integrated the way it
> was. IMHO, it lacks any kind of reality. Has the SDK been ever tested
> against python based host development systems? My assumption is no. I
> do not think there is any sanity in using a _that_ stripped down
> version of python on desktop. It just really hurts the python users
> for the SDK, since there is no simple workaround and we cannot get the
> SDK to let the system python take precedence. This situation is awful
> in my opinion. Who is up for fixing this in the core? Let us have a
> _standard_ python shipped with the SDK by default or do not ship any
> at all.

If you install nativesdk-python-modules into your SDK, you will get
python *and* all its modules installed. If you just install the python
core, you get a cut down python and need to install the modules you
need.

The python SDK has been tested and used in a number of scenarios. Where
a full set of modules is needed, nativesdk-python-modules gets installed
and everyone is happy. If there is some problem with
nativesdk-python-modules, please let us know.

Cheers,

Richard



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

Re: [OE-core] [PATCH 1/2] nativesdk-packagegroup-python: buildtools-tarball: Introduce NativeSDK package group

2014-09-18 Thread Richard Purdie

On Thu, 2014-09-18 at 11:15 +0200, Marek Vasut wrote:
> Introduce and use nativesdk-packagegroup-python , which contains all
> necessary python components for the native SDK. Make use of this
> package group in buildtools-tarball.bb immediatelly.

Specifically, isn't this the list of packages needed to run bitbake and
its associated utils? "python" isn't therefore a particularly good
description of this package?

Cheers,

Richard

> Signed-off-by: Marek Vasut 
> ---
>  meta/recipes-core/meta/buildtools-tarball.bb   | 28 +
>  .../python/nativesdk-packagegroup-python.bb| 36 
> ++
>  2 files changed, 37 insertions(+), 27 deletions(-)
>  create mode 100644 
> meta/recipes-devtools/python/nativesdk-packagegroup-python.bb
> 
> diff --git a/meta/recipes-core/meta/buildtools-tarball.bb 
> b/meta/recipes-core/meta/buildtools-tarball.bb
> index 62e1e0b..7d20238 100644
> --- a/meta/recipes-core/meta/buildtools-tarball.bb
> +++ b/meta/recipes-core/meta/buildtools-tarball.bb
> @@ -8,33 +8,7 @@ LIC_FILES_CHKSUM = 
> "file://${COREBASE}/LICENSE;md5=4d92cd373abda3937c2bc47fbc49d
>  TOOLCHAIN_TARGET_TASK ?= ""
>  
>  TOOLCHAIN_HOST_TASK ?= "\
> -nativesdk-python-core \
> -nativesdk-python-textutils \
> -nativesdk-python-sqlite3 \
> -nativesdk-python-pickle \
> -nativesdk-python-logging \
> -nativesdk-python-elementtree \
> -nativesdk-python-curses \
> -nativesdk-python-compile \
> -nativesdk-python-compiler \
> -nativesdk-python-fcntl \
> -nativesdk-python-shell \
> -nativesdk-python-misc \
> -nativesdk-python-multiprocessing \
> -nativesdk-python-subprocess \
> -nativesdk-python-xmlrpc \
> -nativesdk-python-netclient \
> -nativesdk-python-netserver \
> -nativesdk-python-distutils \
> -nativesdk-python-unixadmin \
> -nativesdk-python-compression \
> -nativesdk-python-json \
> -nativesdk-python-unittest \
> -nativesdk-python-mmap \
> -nativesdk-python-difflib \
> -nativesdk-python-pprint \
> -nativesdk-python-git \
> -nativesdk-python-pkgutil \
> +nativesdk-packagegroup-python \
>  nativesdk-ncurses-terminfo-base \
>  nativesdk-chrpath \
>  nativesdk-tar \
> diff --git a/meta/recipes-devtools/python/nativesdk-packagegroup-python.bb 
> b/meta/recipes-devtools/python/nativesdk-packagegroup-python.bb
> new file mode 100644
> index 000..fdc1006
> --- /dev/null
> +++ b/meta/recipes-devtools/python/nativesdk-packagegroup-python.bb
> @@ -0,0 +1,36 @@
> +SUMMARY = "NativeSDK Python package group"
> +DESCRIPTION = "NativeSDK Python package group"
> +PR = "r0"
> +LICENSE = "MIT"
> +
> +inherit packagegroup
> +
> +RDEPENDS_${PN} = "   \
> + nativesdk-python-core   \
> + nativesdk-python-textutils  \
> + nativesdk-python-sqlite3\
> + nativesdk-python-pickle \
> + nativesdk-python-logging\
> + nativesdk-python-elementtree\
> + nativesdk-python-curses \
> + nativesdk-python-compile\
> + nativesdk-python-compiler   \
> + nativesdk-python-fcntl  \
> + nativesdk-python-shell  \
> + nativesdk-python-misc   \
> + nativesdk-python-multiprocessing\
> + nativesdk-python-subprocess \
> + nativesdk-python-xmlrpc \
> + nativesdk-python-netclient  \
> + nativesdk-python-netserver  \
> + nativesdk-python-distutils  \
> + nativesdk-python-unixadmin  \
> + nativesdk-python-compression\
> + nativesdk-python-json   \
> + nativesdk-python-unittest   \
> + nativesdk-python-mmap   \
> + nativesdk-python-difflib\
> + nativesdk-python-pprint \
> + nativesdk-python-git\
> + nativesdk-python-pkgutil\
> +"


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

Re: [OE-core] [PATCH] Yocto: Install full set of python modules in Qt SDK toolchain

On Thu, Sep 18, 2014 at 10:30 AM, Marek Vasut  wrote:
> On Thursday, September 18, 2014 at 11:23:13 AM, Laszlo Papp wrote:
>> On Thu, Sep 18, 2014 at 10:16 AM, Marek Vasut  wrote:
>> > On Thursday, September 18, 2014 at 11:11:45 AM, Laszlo Papp wrote:
>> >> Come on, Yocto maintainers, please...
>> >>
>> >> Mark sent this change relatively long ago, and it is still in "new"
>> >> state, sadly. The current SDK shipped _breaks_ any third-party
>> >> software that uses standard python with regards to the libraries and
>> >> all that.
>> >>
>> >> This is is slightly frustrating. We also face the same issue. :(
>> >
>> > Thanks for the reminder, new version which should fix the issues with the
>> > previous one is on the ML now. You're all on CC.
>>
>> I do not think this is an explicit Qt issue, and hence fixing on that
>> layer sounds like a weird approach. It seems to be a generic python
>> issue and so, I think it should be addressed in its core. I opened a
>> new report for this:
>>
>> https://bugzilla.yoctoproject.org/show_bug.cgi?id=6735
>
> Then you probably want to add nativesdk-packagegroup-python class into the 
> other
> toolchain recipes as well . Or even better, into the base SDK toolchain class
> (is there one?)

See, I do not understand why this "feature" was integrated the way it
was. IMHO, it lacks any kind of reality. Has the SDK been ever tested
against python based host development systems? My assumption is no. I
do not think there is any sanity in using a _that_ stripped down
version of python on desktop. It just really hurts the python users
for the SDK, since there is no simple workaround and we cannot get the
SDK to let the system python take precedence. This situation is awful
in my opinion. Who is up for fixing this in the core? Let us have a
_standard_ python shipped with the SDK by default or do not ship any
at all.
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 0/9] V2: Add machine qemuaarch64


On 2014年09月17日 23:11, Burton, Ross wrote:

On 16 September 2014 16:06, Kai Kang  wrote:

V2:
* fix kernel linux-yocto build faiure
* redefine position of dynamic linker from /lib to /lib64
* other fixes of userspace packages

Test with Joe Slater's patches:
* siteinfo: account for 32 and 64 bit arm
* sysprof: add aarch64 support

So aarch64 support really needs qemuarm64 in oe-core to be tested, and
qemuarm64 is a new feature, and we froze for new features two weeks
ago.  Blindly merging aarch64 patches that we can't currently test
doesn't seem sensible.

Could someone who is actually testing and working on the aarch64
support (you?) manage a single branch that tracks master, so when 1.7
branches off we can do a merge straight away.


OK. We will continue to work on arch aarch64 and do runtime tests.

--Kai



Ross





--
Regards,
Neil | Kai Kang

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

Re: [OE-core] [PATCH 9/9] perf: disable libunwind support for aarch64


On 2014年09月18日 15:07, Khem Raj wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1



On 9/16/14 8:06 AM, Kai Kang wrote:

Disable libunwind support of perl for aarch aarch64 that libunwind
doesn't support aarch64.

Signed-off-by: Kai Kang 
---
  meta/recipes-kernel/perf/perf-features.inc | 1 +
  1 file changed, 1 insertion(+)

diff --git a/meta/recipes-kernel/perf/perf-features.inc 
b/meta/recipes-kernel/perf/perf-features.inc
index 2dbbb47..1782ae6 100644
--- a/meta/recipes-kernel/perf/perf-features.inc
+++ b/meta/recipes-kernel/perf/perf-features.inc
@@ -1,4 +1,5 @@
  PERF_FEATURES_ENABLE ?= "perf-scripting perf-tui perf-libunwind"
+PERF_FEATURES_ENABLE_aarch64 ?= "perf-scripting perf-tui"
  

you could also say PERF_FEATURES_ENABLE_remove_aarch64 = "perf-libunwind"


Thanks. I'll try it.

--Kai




  def perf_feature_enabled(feature, trueval, falseval, d):
  """

- -- 
- -Khem

-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
Comment: GPGTools - https://gpgtools.org

iEYEARECAAYFAlQahLUACgkQuwUzVZGdMxRUTgCbB9mselfaJ3OdHJTFnZp34n15
OacAni2H6G+Mri1zW7+W5OCHBbgzfE5L
=lgJC
-END PGP SIGNATURE-



--
Regards,
Neil | Kai Kang

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

Re: [OE-core] [PATCH 3/9] gcc-4.9: redefine dynamic linker for aarch64


On 2014年09月18日 15:19, Khem Raj wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1



On 9/16/14 8:06 AM, Kai Kang wrote:

Redefine dynamic linker for aarch64 from /lib to /lib64.

BASELIB of aarch64 has to be defined with 'lib64', then linker file
ld-linux-aarch64.so.1 is installed into /lib64 rather than /lib. So
update it here too.

hmmm since the ldso name is different it can still live in /lib
and there will be ilp32 version ldso multilib as well later. can we keep
ldso in /lib ?


Should not we use '/lib64' and '/lib' for mutlilib? I remember 
intel-x86-64 uses that way rather than '/lib' and '/lib32'.


--Kai




Signed-off-by: Kai Kang 
---
  meta/recipes-devtools/gcc/gcc-4.9.inc  |  1 +
  .../0056-redefine-dynamic-linker-for-aarch64.patch | 34 ++
  2 files changed, 35 insertions(+)
  create mode 100644 
meta/recipes-devtools/gcc/gcc-4.9/0056-redefine-dynamic-linker-for-aarch64.patch

diff --git a/meta/recipes-devtools/gcc/gcc-4.9.inc 
b/meta/recipes-devtools/gcc/gcc-4.9.inc
index 25778bd..c434a45 100644
--- a/meta/recipes-devtools/gcc/gcc-4.9.inc
+++ b/meta/recipes-devtools/gcc/gcc-4.9.inc
@@ -70,6 +70,7 @@ SRC_URI = "\
  file://0053-gcc-fix-segfault-from-calling-free-on-non-malloc-d-a.patch \
  file://0054-gcc-Makefile.in-fix-parallel-building-failure.patch \
  file://0055-PR-rtl-optimization-61801.patch \
+file://0056-redefine-dynamic-linker-for-aarch64.patch \
  "
  SRC_URI[md5sum] = "fddf71348546af523353bd43d34919c1"
  SRC_URI[sha256sum] = 
"d334781a124ada6f38e63b545e2a3b8c2183049515a1abab6d513f109f1d717e"
diff --git 
a/meta/recipes-devtools/gcc/gcc-4.9/0056-redefine-dynamic-linker-for-aarch64.patch
 
b/meta/recipes-devtools/gcc/gcc-4.9/0056-redefine-dynamic-linker-for-aarch64.patch
new file mode 100644
index 000..6933e2f
--- /dev/null
+++ 
b/meta/recipes-devtools/gcc/gcc-4.9/0056-redefine-dynamic-linker-for-aarch64.patch
@@ -0,0 +1,34 @@
+From 8fbb60d89e569b68b13e4fd419e20640eb49cabc Mon Sep 17 00:00:00 2001
+From: Kai Kang 
+Date: Tue, 16 Sep 2014 16:01:31 +0800
+Subject: [PATCH] Redefine dynamic linker for aarch64
+
+Redefine dynamic linker for aarch64 from /lib to /lib64.
+
+BASELIB of aarch64 has to be defined with 'lib64', then linker file
+ld-linux-aarch64.so.1 is installed into /lib64 rather than /lib. So
+update it here too.
+
+Upstream-Status: Pending
+
+Signed-off-by: Kai Kang 
+---
+ gcc/config/aarch64/aarch64-linux.h | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/gcc/config/aarch64/aarch64-linux.h 
b/gcc/config/aarch64/aarch64-linux.h
+index a8f0771..2a6f06d 100644
+--- a/gcc/config/aarch64/aarch64-linux.h
 b/gcc/config/aarch64/aarch64-linux.h
+@@ -21,7 +21,7 @@
+ #ifndef GCC_AARCH64_LINUX_H
+ #define GCC_AARCH64_LINUX_H
+
+-#define GLIBC_DYNAMIC_LINKER "/lib/ld-linux-aarch64%{mbig-endian:_be}.so.1"
++#define GLIBC_DYNAMIC_LINKER "/lib64/ld-linux-aarch64%{mbig-endian:_be}.so.1"
+
+ #define CPP_SPEC "%{pthread:-D_REENTRANT}"
+
+--
+1.9.1
+

- -- 
- -Khem

-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
Comment: GPGTools - https://gpgtools.org

iEYEARECAAYFAlQah2UACgkQuwUzVZGdMxT98wCghPbcAP/2xFgFn9Lv3Wisexa6
kHkAni6hykOqPq44VheOimbMbcimHaZD
=jpy6
-END PGP SIGNATURE-



--
Regards,
Neil | Kai Kang

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

Re: [OE-core] [PATCH] Yocto: Install full set of python modules in Qt SDK toolchain

On Thursday, September 18, 2014 at 11:23:13 AM, Laszlo Papp wrote:
> On Thu, Sep 18, 2014 at 10:16 AM, Marek Vasut  wrote:
> > On Thursday, September 18, 2014 at 11:11:45 AM, Laszlo Papp wrote:
> >> Come on, Yocto maintainers, please...
> >> 
> >> Mark sent this change relatively long ago, and it is still in "new"
> >> state, sadly. The current SDK shipped _breaks_ any third-party
> >> software that uses standard python with regards to the libraries and
> >> all that.
> >> 
> >> This is is slightly frustrating. We also face the same issue. :(
> > 
> > Thanks for the reminder, new version which should fix the issues with the
> > previous one is on the ML now. You're all on CC.
> 
> I do not think this is an explicit Qt issue, and hence fixing on that
> layer sounds like a weird approach. It seems to be a generic python
> issue and so, I think it should be addressed in its core. I opened a
> new report for this:
> 
> https://bugzilla.yoctoproject.org/show_bug.cgi?id=6735

Then you probably want to add nativesdk-packagegroup-python class into the 
other 
toolchain recipes as well . Or even better, into the base SDK toolchain class 
(is there one?)

Best regards,
Marek Vasut
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 1/9] linux-yocto: depend on libgcc for aarch64


On 2014年09月18日 14:56, Khem Raj wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1



On 9/16/14 8:06 AM, Kai Kang wrote:

Make aarch aarch64 kernel depend on libgcc. In arch/arm64/Makefile, it
adds LIBGCC to libs-y:

LIBGCC  := $(shell $(CC) $(KBUILD_CFLAGS) -print-libgcc-file-name)
libs-y  += $(LIBGCC)

If build without libgcc, the value of LIBGCC is just libgcc.a without
parent directory. linux-yocto fails to build:

|   LD  vmlinux.o
| aarch64-poky-linux-ld.bfd: cannot find libgcc.a: No such file or directory

Add libgcc to aarch64 kernel dependency.

really ? usually kernel has its own routines to substitute libgcc needs.
why is it different here.


It calls script link-vmlinux.sh to link vmlinux.o. It runs function 
vmlinux_link() in the script:


if [ "${SRCARCH}" != "um" ]; then
${LD} ${LDFLAGS} ${LDFLAGS_vmlinux} -o ${2} \
-T ${lds} ${KBUILD_VMLINUX_INIT} \
--start-group ${KBUILD_VMLINUX_MAIN} --end-group ${1}

var KBUILD_VMLINUX_MAIN is defined in top Makefile:

export KBUILD_VMLINUX_MAIN := $(core-y) $(libs-y) $(drivers-y) $(net-y)


And arch aarch64 adds LIBGCC to var libs-y:

LIBGCC  := $(shell $(CC) $(KBUILD_CFLAGS) -print-libgcc-file-name)
libs-y  += $(LIBGCC)


If doesn't do libgcc:popualte_sysroot, LIBGCC just get value 'libgcc.a' 
rather than 'absolute path' to libgcc.a.


In script link-vmlinux.sh, it expands to:

+ modpost_link vmlinux.o
+ aarch64-poky-linux-ld.bfd -r -o vmlinux.o arch/arm64/kernel/head.o 
init/built-in.o --start-group usr/built-in.o 
arch/arm64/kernel/built-in.o arch/arm64/mm/built-in.o kernel/built-in.o 
mm/built-in.o fs/built-in.o ipc/built-in.o security/built-in.o 
crypto/built-in.o block/built-in.o arch/arm64/lib/lib.a lib/lib.a 
*libgcc.a* arch/arm64/lib/built-in.o lib/built-in.o *libgcc.a* 
drivers/built-in.o sound/built-in.o firmware/built-in.o net/built-in.o 
--end-group


Because no libgcc.a in current directory, error shows twice:

aarch64-poky-linux-ld.bfd: cannot find libgcc.a: No such file or directory
aarch64-poky-linux-ld.bfd: cannot find libgcc.a: No such file or directory

So I add libgcc as dependency of aarch64 kernel.


And one thing more, in kernel source directory arch, only few arches 
depends on LIBGCC:


$ grep -rw LIBGCC arch/
./openrisc/Makefile:LIBGCC := $(shell $(CC) $(KBUILD_CFLAGS) 
-print-libgcc-file-name)

./openrisc/Makefile:libs-y += $(LIBGCC)
./parisc/Makefile:LIBGCC = $(shell $(CC) $(KBUILD_CFLAGS) 
-print-libgcc-file-name)

./parisc/Makefile:libs-y += arch/parisc/lib/ $(LIBGCC)
./hexagon/Makefile:LIBGCC := $(shell $(CC) $(KBUILD_CFLAGS) 
-print-libgcc-file-name)

./hexagon/Makefile:libs-y += $(LIBGCC)
./arc/Makefile:LIBGCC := $(shell $(CC) $(ARC_LIBGCC) $(cflags-y) 
--print-libgcc-file-name)

./arc/Makefile:libs-y += arch/arc/lib/ $(LIBGCC)
./m32r/Makefile:LIBGCC := $(shell $(CC) $(KBUILD_CFLAGS) 
-print-libgcc-file-name)

./m32r/Makefile:libs-y += arch/m32r/lib/ $(LIBGCC)
./xtensa/Makefile:LIBGCC := $(shell $(CC) $(KBUILD_CFLAGS) 
-print-libgcc-file-name)

./xtensa/Makefile:libs-y += arch/xtensa/lib/ $(LIBGCC)
./xtensa/boot/boot-redboot/Makefile:LIBGCC := $(shell $(CC) 
$(KBUILD_CFLAGS) -print-libgcc-file-name)
./xtensa/boot/boot-redboot/Makefile: $(Q)$(LD) $(LD_ARGS) -o $@ $^ 
-L/xtensa-elf/lib $(LIBGCC)
./cris/Makefile:LIBGCC = $(shell $(CC) $(KBUILD_CFLAGS) 
-print-file-name=libgcc.a)

./cris/Makefile:libs-y += arch/cris/$(SARCH)/lib/ $(LIBGCC)
./arm64/Makefile:LIBGCC := $(shell $(CC) $(KBUILD_CFLAGS) 
-print-libgcc-file-name)

./arm64/Makefile:libs-y += $(LIBGCC)


By coincidence, there is no arch Yocto support before.

Regards,
Kai





Signed-off-by: Kai Kang 
---
  meta/recipes-kernel/linux/linux-yocto.inc | 1 +
  1 file changed, 1 insertion(+)

diff --git a/meta/recipes-kernel/linux/linux-yocto.inc 
b/meta/recipes-kernel/linux/linux-yocto.inc
index 4ed3188..db693e6 100644
--- a/meta/recipes-kernel/linux/linux-yocto.inc
+++ b/meta/recipes-kernel/linux/linux-yocto.inc
@@ -7,6 +7,7 @@ LIC_FILES_CHKSUM = 
"file://COPYING;md5=d7810fab7487fb0aad327b76f1be7cd7"
  INC_PR = "r4"
  
  DEPENDS += "xz-native bc-native"

+DEPENDS_aarch64 += "libgcc"
  

this should be using append instead of +=


OK.

Thanks,
--Kai




  # A KMACHINE is the mapping of a yocto $MACHINE to what is built
  # by the kernel. This is typically the branch that should be built,

- -- 
- -Khem

-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
Comment: GPGTools - https://gpgtools.org

iEYEARECAAYFAlQagi0ACgkQuwUzVZGdMxQfGwCaAuY+dIXbAnQ9tTOIA4MFSwhe
wEwAn1FxFeun292octWdy0sYJqtGRPOb
=5Tcg
-END PGP SIGNATURE-



--
Regards,
Neil | Kai Kang

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

Re: [OE-core] [PATCH] Yocto: Install full set of python modules in Qt SDK toolchain

On Thu, Sep 18, 2014 at 10:16 AM, Marek Vasut  wrote:
> On Thursday, September 18, 2014 at 11:11:45 AM, Laszlo Papp wrote:
>> Come on, Yocto maintainers, please...
>>
>> Mark sent this change relatively long ago, and it is still in "new"
>> state, sadly. The current SDK shipped _breaks_ any third-party
>> software that uses standard python with regards to the libraries and
>> all that.
>>
>> This is is slightly frustrating. We also face the same issue. :(
>
> Thanks for the reminder, new version which should fix the issues with the
> previous one is on the ML now. You're all on CC.

I do not think this is an explicit Qt issue, and hence fixing on that
layer sounds like a weird approach. It seems to be a generic python
issue and so, I think it should be addressed in its core. I opened a
new report for this:

https://bugzilla.yoctoproject.org/show_bug.cgi?id=6735
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 2/2] meta-toolchain-qt: Install full set of python modules in Qt SDK toolchain

The Qt SDK toolchain pulls in python via packagegroup-cross-canadian-${MACHINE}
and ships it. But the python is missing many modules and is rather incomplete.

The environment-setup-* script configures the PATH variable to point into
it's own sysroot first, it means the python from the SDK is used as well
when the environment is configured. It actually does make sense to use the
python from the SDK, since the SDK should provide the tools needed to build
additional software.

The problem is, the python in the SDK image is stripped to a bare minimum
of modules, which prevents some software from being built with the SDK as
is. Add the same python modules as the buildtools-tarball.bb adds to make
the python shipped with the SDK complete via nativesdk-packagegroup-python.

Signed-off-by: Marek Vasut 
---
 meta/recipes-qt/meta/meta-toolchain-qt.inc | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-qt/meta/meta-toolchain-qt.inc 
b/meta/recipes-qt/meta/meta-toolchain-qt.inc
index 6b162bd..b8b9c78 100644
--- a/meta/recipes-qt/meta/meta-toolchain-qt.inc
+++ b/meta/recipes-qt/meta/meta-toolchain-qt.inc
@@ -1,4 +1,8 @@
-TOOLCHAIN_HOST_TASK = "nativesdk-packagegroup-${QTNAME}-toolchain-host 
packagegroup-cross-canadian-${MACHINE}"
+TOOLCHAIN_HOST_TASK = " \
+   nativesdk-packagegroup-${QTNAME}-toolchain-host \
+   packagegroup-cross-canadian-${MACHINE} \
+   nativesdk-packagegroup-python \
+   "
 TOOLCHAIN_TARGET_TASK = "packagegroup-${QTNAME}-toolchain-target"
 TOOLCHAIN_OUTPUTNAME = "${SDK_NAME}-toolchain-${QTNAME}-${DISTRO_VERSION}"
 
-- 
2.0.0

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

Re: [OE-core] [PATCH] Yocto: Install full set of python modules in Qt SDK toolchain

On Thursday, September 18, 2014 at 11:11:45 AM, Laszlo Papp wrote:
> Come on, Yocto maintainers, please...
> 
> Mark sent this change relatively long ago, and it is still in "new"
> state, sadly. The current SDK shipped _breaks_ any third-party
> software that uses standard python with regards to the libraries and
> all that.
> 
> This is is slightly frustrating. We also face the same issue. :(

Thanks for the reminder, new version which should fix the issues with the 
previous one is on the ML now. You're all on CC.

Best regards,
Marek Vasut
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 1/2] nativesdk-packagegroup-python: buildtools-tarball: Introduce NativeSDK package group

Introduce and use nativesdk-packagegroup-python , which contains all
necessary python components for the native SDK. Make use of this
package group in buildtools-tarball.bb immediatelly.

Signed-off-by: Marek Vasut 
---
 meta/recipes-core/meta/buildtools-tarball.bb   | 28 +
 .../python/nativesdk-packagegroup-python.bb| 36 ++
 2 files changed, 37 insertions(+), 27 deletions(-)
 create mode 100644 
meta/recipes-devtools/python/nativesdk-packagegroup-python.bb

diff --git a/meta/recipes-core/meta/buildtools-tarball.bb 
b/meta/recipes-core/meta/buildtools-tarball.bb
index 62e1e0b..7d20238 100644
--- a/meta/recipes-core/meta/buildtools-tarball.bb
+++ b/meta/recipes-core/meta/buildtools-tarball.bb
@@ -8,33 +8,7 @@ LIC_FILES_CHKSUM = 
"file://${COREBASE}/LICENSE;md5=4d92cd373abda3937c2bc47fbc49d
 TOOLCHAIN_TARGET_TASK ?= ""
 
 TOOLCHAIN_HOST_TASK ?= "\
-nativesdk-python-core \
-nativesdk-python-textutils \
-nativesdk-python-sqlite3 \
-nativesdk-python-pickle \
-nativesdk-python-logging \
-nativesdk-python-elementtree \
-nativesdk-python-curses \
-nativesdk-python-compile \
-nativesdk-python-compiler \
-nativesdk-python-fcntl \
-nativesdk-python-shell \
-nativesdk-python-misc \
-nativesdk-python-multiprocessing \
-nativesdk-python-subprocess \
-nativesdk-python-xmlrpc \
-nativesdk-python-netclient \
-nativesdk-python-netserver \
-nativesdk-python-distutils \
-nativesdk-python-unixadmin \
-nativesdk-python-compression \
-nativesdk-python-json \
-nativesdk-python-unittest \
-nativesdk-python-mmap \
-nativesdk-python-difflib \
-nativesdk-python-pprint \
-nativesdk-python-git \
-nativesdk-python-pkgutil \
+nativesdk-packagegroup-python \
 nativesdk-ncurses-terminfo-base \
 nativesdk-chrpath \
 nativesdk-tar \
diff --git a/meta/recipes-devtools/python/nativesdk-packagegroup-python.bb 
b/meta/recipes-devtools/python/nativesdk-packagegroup-python.bb
new file mode 100644
index 000..fdc1006
--- /dev/null
+++ b/meta/recipes-devtools/python/nativesdk-packagegroup-python.bb
@@ -0,0 +1,36 @@
+SUMMARY = "NativeSDK Python package group"
+DESCRIPTION = "NativeSDK Python package group"
+PR = "r0"
+LICENSE = "MIT"
+
+inherit packagegroup
+
+RDEPENDS_${PN} = " \
+   nativesdk-python-core   \
+   nativesdk-python-textutils  \
+   nativesdk-python-sqlite3\
+   nativesdk-python-pickle \
+   nativesdk-python-logging\
+   nativesdk-python-elementtree\
+   nativesdk-python-curses \
+   nativesdk-python-compile\
+   nativesdk-python-compiler   \
+   nativesdk-python-fcntl  \
+   nativesdk-python-shell  \
+   nativesdk-python-misc   \
+   nativesdk-python-multiprocessing\
+   nativesdk-python-subprocess \
+   nativesdk-python-xmlrpc \
+   nativesdk-python-netclient  \
+   nativesdk-python-netserver  \
+   nativesdk-python-distutils  \
+   nativesdk-python-unixadmin  \
+   nativesdk-python-compression\
+   nativesdk-python-json   \
+   nativesdk-python-unittest   \
+   nativesdk-python-mmap   \
+   nativesdk-python-difflib\
+   nativesdk-python-pprint \
+   nativesdk-python-git\
+   nativesdk-python-pkgutil\
+"
-- 
2.0.0

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

Re: [OE-core] [PATCH] Yocto: Install full set of python modules in Qt SDK toolchain

I meant to write "Marek". I apologize for the spelling issue.

On Thu, Sep 18, 2014 at 10:11 AM, Laszlo Papp  wrote:
> Come on, Yocto maintainers, please...
>
> Mark sent this change relatively long ago, and it is still in "new"
> state, sadly. The current SDK shipped _breaks_ any third-party
> software that uses standard python with regards to the libraries and
> all that.
>
> This is is slightly frustrating. We also face the same issue. :(
>
> On Mon, Aug 11, 2014 at 7:26 PM, Marek Vasut  wrote:
>> On Monday, August 11, 2014 at 12:26:34 PM, Richard Purdie wrote:
>>> On Fri, 2014-08-08 at 14:22 +0200, Marek Vasut wrote:
>>> > On Friday, August 08, 2014 at 07:22:04 AM, Koen Kooi wrote:
>>> > > Since 'yocto' is a project like freedesktop.org your commit message
>>> > > doesn't make sense, it should be something like:
>>> > >
>>> > > meta-toolchain-qt:  Install full set of python modules
>>> >
>>> > Got it, Saul also told me so. I will wait a bit for some more feedback
>>> > and repost with corrections, OK ? Is this approach I took here even
>>> > correct please ?
>>>
>>> I'd really like to see a packagegroup defined somewhere with this list
>>> of python modules which the various recipes can then reference...
>>
>> I agree, that makes sense. Is this approach I took here the correct one 
>> please ?
>>
>> Best regards,
>> Marek Vasut
>> --
>> ___
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.openembedded.org/mailman/listinfo/openembedded-core
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] Yocto: Install full set of python modules in Qt SDK toolchain

Come on, Yocto maintainers, please...

Mark sent this change relatively long ago, and it is still in "new"
state, sadly. The current SDK shipped _breaks_ any third-party
software that uses standard python with regards to the libraries and
all that.

This is is slightly frustrating. We also face the same issue. :(

On Mon, Aug 11, 2014 at 7:26 PM, Marek Vasut  wrote:
> On Monday, August 11, 2014 at 12:26:34 PM, Richard Purdie wrote:
>> On Fri, 2014-08-08 at 14:22 +0200, Marek Vasut wrote:
>> > On Friday, August 08, 2014 at 07:22:04 AM, Koen Kooi wrote:
>> > > Since 'yocto' is a project like freedesktop.org your commit message
>> > > doesn't make sense, it should be something like:
>> > >
>> > > meta-toolchain-qt:  Install full set of python modules
>> >
>> > Got it, Saul also told me so. I will wait a bit for some more feedback
>> > and repost with corrections, OK ? Is this approach I took here even
>> > correct please ?
>>
>> I'd really like to see a packagegroup defined somewhere with this list
>> of python modules which the various recipes can then reference...
>
> I agree, that makes sense. Is this approach I took here the correct one 
> please ?
>
> Best regards,
> Marek Vasut
> --
> ___
> 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

[OE-core] [PATCH] qtdemo-init: Make qtdemo startup correctly

2014-09-18 Thread Yi Zhao

The qtdemo can't launch via qtdemo-init initscript. Fix it.

Signed-off-by: Yi Zhao 
---
 meta/recipes-qt/qt-demo/qt-demo-init/qtdemo-init |   10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/meta/recipes-qt/qt-demo/qt-demo-init/qtdemo-init 
b/meta/recipes-qt/qt-demo/qt-demo-init/qtdemo-init
index 3a1f2cb..21f0273 100644
--- a/meta/recipes-qt/qt-demo/qt-demo-init/qtdemo-init
+++ b/meta/recipes-qt/qt-demo/qt-demo-init/qtdemo-init
@@ -2,8 +2,8 @@
 
 set -e
 
-if [ -f /usr/bin/qtdemo ]; then
-   QTDEMO="qtdemo > /var/log/Xsession.log 2> &1"
+if [ -x /usr/bin/qtdemo ]; then
+   QTDEMO="qtdemo"
 else
QTDEMO="qtdemoE -qws"
 fi
@@ -18,7 +18,7 @@ case "$1" in
if [ ! -f /etc/pointercal ]; then
/usr/bin/ts_calibrate
fi
-   if [ "$QTDEMO" = qtdemo ]; then
+   if [ "$QTDEMO" = "qtdemo" ]; then
Xorg &
export DISPLAY=:0
$QTDEMO &
@@ -26,7 +26,7 @@ case "$1" in
QWS_MOUSE_PROTO=tslib:$TSLIB_TSDEVICE $QTDEMO &
fi
else
-   if [ "$QTDEMO" = qtdemo ]; then
+   if [ "$QTDEMO" = "qtdemo" ]; then
Xorg &
export DISPLAY=:0
fi
@@ -35,7 +35,7 @@ case "$1" in
;;
   stop)
echo "Stopping qtdemo"
-   if [ "$QTDEMO" = qtdemo ]; then
+   if [ "$QTDEMO" = "qtdemo" ]; then
killall Xorg
killall qtdemo
else
-- 
1.7.9.5

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

[OE-core] [PATCH 1/1] gstreamer1.0-plugins-bad: disable libssh2

2014-09-18 Thread wenzong.fan

From: Wenzong Fan 

libssh2 is automatically linked to if present, this undetermined
dependency may cause build errors like:

  .../x86_64-poky-linux/4.9.0/ld: cannot find -lssh2

libssh2 isn't an oe-core recipe, disable it for now.

Signed-off-by: Wenzong Fan 
---
 .../gstreamer/gstreamer1.0-plugins-bad.inc |4 ++
 .../configure-allow-to-disable-libssh2.patch   |   64 
 2 files changed, 68 insertions(+)
 create mode 100644 
meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad/configure-allow-to-disable-libssh2.patch

diff --git a/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad.inc 
b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad.inc
index d8aa6ee..dab0bf5 100644
--- a/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad.inc
+++ b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad.inc
@@ -6,6 +6,9 @@ DEPENDS += "gstreamer1.0-plugins-base bzip2 libpng jpeg"
 
 S = "${WORKDIR}/gst-plugins-bad-${PV}"
 
+SRC_URI += "file://configure-allow-to-disable-libssh2.patch \
+   "
+
 inherit gettext
 
 # opengl packageconfig factored out to make it easy for distros
@@ -51,6 +54,7 @@ PACKAGECONFIG[rsvg]= 
"--enable-rsvg,--disable-rsvg,librsvg"
 PACKAGECONFIG[sndfile] = 
"--enable-sndfile,--disable-sndfile,libsndfile1"
 PACKAGECONFIG[webp]= "--enable-webp,--disable-webp,libwebp"
 PACKAGECONFIG[rtmp]= "--enable-rtmp,--disable-rtmp,rtmpdump"
+PACKAGECONFIG[libssh2] = "--enable-libssh2,--disable-libssh2,libssh2"
 
 # these plugins have not been ported to 1.0 (yet):
 #   directdraw vcd apexsink dc1394 lv2 linsys musepack mythtv
diff --git 
a/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad/configure-allow-to-disable-libssh2.patch
 
b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad/configure-allow-to-disable-libssh2.patch
new file mode 100644
index 000..d52afd5
--- /dev/null
+++ 
b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad/configure-allow-to-disable-libssh2.patch
@@ -0,0 +1,64 @@
+From f59c5269f92d59a5296cbfeeb682d42095cd88ad Mon Sep 17 00:00:00 2001
+From: Wenzong Fan 
+Date: Thu, 18 Sep 2014 02:24:07 -0400
+Subject: [PATCH] gstreamer1.0-plugins-bad: allow to disable libssh2
+
+libssh2 is automatically linked to if present, this undetermined
+dependency may cause build errors like:
+
+  .../x86_64-poky-linux/4.9.0/ld: cannot find -lssh2
+
+libssh2 isn't an oe-core recipe, so allow to disable it from
+configure.
+
+Upstream-Status: Pending
+
+Signed-off-by: Wenzong Fan 
+---
+ configure.ac |   23 +--
+ 1 file changed, 17 insertions(+), 6 deletions(-)
+
+diff --git a/configure.ac b/configure.ac
+index 0e95c5c..12153b4 100644
+--- a/configure.ac
 b/configure.ac
+@@ -1901,6 +1901,15 @@ AG_GST_CHECK_FEATURE(CHROMAPRINT, [chromaprint], 
chromaprint, [
+ ])
+ 
+ dnl *** Curl ***
++AC_ARG_ENABLE([libssh2],
++ [  --enable-libssh2  enable LIBSSH2 support 
@<:@default=auto@:>@],
++ [case "${enableval}" in
++   yes)  NEED_SSH2=yes ;;
++   no)   NEED_SSH2=no ;;
++   auto) NEED_SSH2=auto ;;
++   *) AC_MSG_ERROR([bad value ${enableval} for --enable-libssh2]) ;;
++ esac],[NEED_SSH2=auto])
++
+ translit(dnm, m, l) AM_CONDITIONAL(USE_CURL, true)
+ AG_GST_CHECK_FEATURE(CURL, [Curl plugin], curl, [
+   PKG_CHECK_MODULES(CURL, libcurl >= 7.21.0, [
+@@ -1915,12 +1924,14 @@ AG_GST_CHECK_FEATURE(CURL, [Curl plugin], curl, [
+   ])
+   AC_SUBST(CURL_CFLAGS)
+   AC_SUBST(CURL_LIBS)
+-  PKG_CHECK_MODULES(SSH2, libssh2 >= 1.4.3, [
+-HAVE_SSH2="yes"
+-AC_DEFINE(HAVE_SSH2, 1, [Define if libssh2 is available])
+-  ], [
+-HAVE_SSH2="no"
+-  ])
++  if test "x$NEED_SSH2" != "xno"; then
++PKG_CHECK_MODULES(SSH2, libssh2 >= 1.4.3, [
++  HAVE_SSH2="yes"
++  AC_DEFINE(HAVE_SSH2, 1, [Define if libssh2 is available])
++], [
++  HAVE_SSH2="no"
++])
++  fi
+   AM_CONDITIONAL(USE_SSH2, test "x$HAVE_SSH2" = "xyes")
+   AC_SUBST(SSH2_CFLAGS)
+   AC_SUBST(SSH2_LIBS)
+-- 
+1.7.9.5
+
-- 
1.7.9.5

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

[OE-core] [PATCH 0/1] gstreamer1.0-plugins-bad: disable libssh2

2014-09-18 Thread wenzong.fan

From: Wenzong Fan 

libssh2 is automatically linked to if present, this undetermined
dependency may cause build errors like:

  .../x86_64-poky-linux/4.9.0/ld: cannot find -lssh2

libssh2 isn't an oe-core recipe, disable it for now.

The following changes since commit 280b6d0011f101e7a8edabd34c265b37a2f791ed:

  sstatesig: fix overrides behaviour to remove SIGGEN_LOCKEDSIGS_i586 
(2014-09-17 22:00:26 +0100)

are available in the git repository at:

  git://git.pokylinux.org/poky-contrib wenzong/gst-plugins-bad
  http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=wenzong/gst-plugins-bad

Wenzong Fan (1):
  gstreamer1.0-plugins-bad: disable libssh2

 .../gstreamer/gstreamer1.0-plugins-bad.inc |4 ++
 .../configure-allow-to-disable-libssh2.patch   |   64 
 2 files changed, 68 insertions(+)
 create mode 100644 
meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad/configure-allow-to-disable-libssh2.patch

-- 
1.7.9.5

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

Re: [OE-core] [daisy][PATCH] qemu: Explicitly disable libiscsi, its not in DEPENDS

2014-09-18 Thread Jonathan Liu

On 29 August 2014 23:48, Jonathan Liu  wrote:
> Signed-off-by: Jonathan Liu 
> ---
>  meta/recipes-devtools/qemu/qemu.inc | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/meta/recipes-devtools/qemu/qemu.inc 
> b/meta/recipes-devtools/qemu/qemu.inc
> index 2702986..472988d 100644
> --- a/meta/recipes-devtools/qemu/qemu.inc
> +++ b/meta/recipes-devtools/qemu/qemu.inc
> @@ -26,7 +26,7 @@ SRC_URI_append_class-native = "\
>  file://fix-libcap-header-issue-on-some-distro.patch \
>  "
>
> -EXTRA_OECONF += "--target-list=${@get_qemu_target_list(d)} --disable-werror 
> --audio-drv-list=oss,alsa --disable-bluez --with-system-pixman 
> --extra-cflags='${CFLAGS}'"
> +EXTRA_OECONF += "--target-list=${@get_qemu_target_list(d)} --disable-werror 
> --audio-drv-list=oss,alsa --disable-bluez --disable-libiscsi 
> --with-system-pixman --extra-cflags='${CFLAGS}'"
>
>  EXTRA_OECONF_class-nativesdk = "--target-list=${@get_qemu_target_list(d)} 
> --disable-werror \
> "
> --
> 2.0.3
>

Ping.

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

Re: [OE-core] [PATCH 0/8] Various fixes to obey LDFLAGS

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1



On 9/3/14 10:27 AM, Christopher Larson wrote:
> From: Christopher Larson 
> 
> This patch series fixes 8 recipes to obey LDFLAGS. These issues are easy to
> miss, now that the internal toolchain defaults to passing the correct
> GNU_HASH, so GNU_HASH warnings when LDFLAGS isn't obeyed are only seen when
> using an external toolchain. These were kept in meta-sourcery or meta-mentor,
> but given these are general correctness fixes, regardless of the lack of
> warnings for most users, I think they're appropriate for upstream inclusion.

may be they should be sent to respective component upstreams first

> 
> The following changes since commit e72aac2ae9e5fce1715fa04b7e94034fd06892d9:
> 
>   alsa-lib: libasound should runtime depends on alsa-conf (2014-09-03 
> 11:30:11 +0100)
> 
> are available in the git repository at:
> 
>   g...@github.com:kergoth/openembedded-core ldflags-fixes
>   https://github.com/kergoth/openembedded-core ldflags-fixes
> 
> for you to fetch changes up to 2cddd349eb9cafbbaf5257fb61beb9dc249df85c:
> 
>   python: obey LDFLAGS (2014-09-03 10:18:37 -0700)
> 
> 
> Christopher Larson (8):
>   zlib: obey LDFLAGS for tests
>   gdbm-1.8.3: obey LDFLAGS
>   ossp-uuid: obey LDFLAGS
>   setserial: obey LDFLAGS
>   hostap-utils: obey LDFLAGS
>   blktrace: obey LDFLAGS for btrecord
>   irda-utils: obey LDFLAGS
>   python: obey LDFLAGS
> 
>  .../hostap/hostap-utils-0.4.7/ldflags.patch| 27 
>  meta/recipes-bsp/hostap/hostap-utils_0.4.7.bb  |  1 +
>  meta/recipes-bsp/setserial/setserial/ldflags.patch | 23 +++
>  meta/recipes-bsp/setserial/setserial_2.17.bb   |  1 +
>  .../irda-utils/irda-utils-0.9.18/ldflags.patch | 79 
> ++
>  .../irda-utils/irda-utils_0.9.18.bb| 18 +++--
>  .../zlib/zlib-1.2.8/ldflags-tests.patch| 45 
>  meta/recipes-core/zlib/zlib_1.2.8.bb   |  1 +
>  .../ossp-uuid/ossp-uuid/ldflags.patch  | 23 +++
>  meta/recipes-devtools/ossp-uuid/ossp-uuid_1.6.2.bb |  1 +
>  meta/recipes-devtools/python/python_2.7.3.bb   |  3 +-
>  .../recipes-kernel/blktrace/blktrace/ldflags.patch |  8 ++-
>  meta/recipes-support/gdbm/gdbm-1.8.3/ldflags.patch | 22 ++
>  meta/recipes-support/gdbm/gdbm_1.8.3.bb|  3 +-
>  14 files changed, 245 insertions(+), 10 deletions(-)
>  create mode 100644 meta/recipes-bsp/hostap/hostap-utils-0.4.7/ldflags.patch
>  create mode 100644 meta/recipes-bsp/setserial/setserial/ldflags.patch
>  create mode 100644 
> meta/recipes-connectivity/irda-utils/irda-utils-0.9.18/ldflags.patch
>  create mode 100644 meta/recipes-core/zlib/zlib-1.2.8/ldflags-tests.patch
>  create mode 100644 meta/recipes-devtools/ossp-uuid/ossp-uuid/ldflags.patch
>  create mode 100644 meta/recipes-support/gdbm/gdbm-1.8.3/ldflags.patch
> 

- -- 
- -Khem
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
Comment: GPGTools - https://gpgtools.org

iEYEARECAAYFAlQaif4ACgkQuwUzVZGdMxSgGACdGG6xSxCtB+8Fe71rw7Uscd/H
LA4AmgNOrOnTSCYUFDTjPPMXsgmnMejp
=IrqW
-END PGP SIGNATURE-
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH v2 6/8] blktrace: obey LDFLAGS for btrecord

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1



On 9/16/14 6:17 PM, Christopher Larson wrote:
> From: Christopher Larson 
> 
> Signed-off-by: Christopher Larson 
> ---
>  meta/recipes-kernel/blktrace/blktrace/ldflags.patch | 8 ++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/meta/recipes-kernel/blktrace/blktrace/ldflags.patch 
> b/meta/recipes-kernel/blktrace/blktrace/ldflags.patch
> index b9c7c20..037d161 100644
> --- a/meta/recipes-kernel/blktrace/blktrace/ldflags.patch
> +++ b/meta/recipes-kernel/blktrace/blktrace/ldflags.patch
> @@ -59,8 +59,12 @@ Signed-off-by: Fahad Usman 
>   INCS= -I. -I.. -I../btt
>   OCFLAGS = -UCOUNT_IOS -UDEBUG -DNDEBUG
>   XCFLAGS = -D_GNU_SOURCE -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
> -@@ -35,7 +36,7 @@ btrecord: btrecord.o
> - $(CC) $(CFLAGS) -o $@ $(filter %.o,$^)
> +@@ -32,10 +33,10 @@ clean: docsclean
> + $(CC) $(CFLAGS) -c -o $*.o $<
> +
> + btrecord: btrecord.o
> +-$(CC) $(CFLAGS) -o $@ $(filter %.o,$^)
> ++$(CC) $(CFLAGS) -o $@ $(filter %.o,$^) $(LDFLAGS)
>   

aren't you passing LDFLAGS to compile step as well here ?


>   btreplay: btreplay.o
>  -$(CC) $(CFLAGS) -o $@ $(filter %.o,$^) $(LIBS)
> 

- -- 
- -Khem
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
Comment: GPGTools - https://gpgtools.org

iEYEARECAAYFAlQaiQoACgkQuwUzVZGdMxT8RgCeOnVS1P+8kPTGj+GbRQfGSPyb
NMAAmgKJL65/3Y5ot35pALZv8ZgRHxQ0
=DxWh
-END PGP SIGNATURE-
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 1/3] sstatesig: Only dump incremental locked signatures

The idea of incremental sig is:

New sig file = Old sig file (if available) + New sig items in current build.

The condition of incremental locked signature dump is an existed locked sig
file is required and it is also the dump sig file.

Signed-off-by: Hongxu Jia 
---
 meta/lib/oe/sstatesig.py | 12 
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/meta/lib/oe/sstatesig.py b/meta/lib/oe/sstatesig.py
index af7617e..56fd953 100644
--- a/meta/lib/oe/sstatesig.py
+++ b/meta/lib/oe/sstatesig.py
@@ -151,19 +151,23 @@ class 
SignatureGeneratorOEBasicHash(bb.siggen.SignatureGeneratorBasicHash):
 types[t] = []
 types[t].append(k)
 
-with open(sigfile, "w") as f:
+with open(sigfile, "a") as f:
 for t in types:
-f.write('SIGGEN_LOCKEDSIGS_%s = "\\\n' % t)
+f.write('SIGGEN_LOCKEDSIGS_%s += "\\\n' % t)
 types[t].sort()
 sortedk = sorted(types[t], key=lambda k: 
self.lockedpnmap[k.rsplit(".",1)[0]])
 for k in sortedk:
 fn = k.rsplit(".",1)[0]
+pn = self.lockedpnmap[fn]
 task = k.rsplit(".",1)[1]
 if k not in self.taskhash:
 continue
-f.write("" + self.lockedpnmap[fn] + ":" + task + ":" + 
self.taskhash[k] + " \\\n")
+if pn in self.lockedsigs and task in self.lockedsigs[pn] 
and self.taskhash[k] == self.lockedsigs[pn][task]:
+continue
+sigentry = pn + ":" + task + ":" + self.taskhash[k]
+f.write("" + sigentry + " \\\n")
 f.write('"\n')
-f.write('SIGGEN_LOCKEDSIGS_TYPES_%s = "%s"' % (self.machine, " 
".join(types.keys(
+f.write('SIGGEN_LOCKEDSIGS_TYPES_%s += "%s"\n' % (self.machine, " 
".join(types.keys(
 
 def checkhashes(self, missed, ret, sq_fn, sq_task, sq_hash, sq_hashfn, d):
 checklevel = d.getVar("SIGGEN_LOCKEDSIGS_CHECK_LEVEL", True)
-- 
1.9.1

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

[OE-core] [PATCH 2/3] sstatesig: add new item checking for locked signature dump

While dumping locked signature, if there is nothing added
in the current build (such as build the same recipe again),
there are accumulating empty SIGGEN_LOCKEDSIGS added, such as:
...
SIGGEN_LOCKEDSIGS_t-x86-64 += "\
"
SIGGEN_LOCKEDSIGS_TYPES_qemux86 += "t-x86-64"

SIGGEN_LOCKEDSIGS_t-x86-64 += "\
"
SIGGEN_LOCKEDSIGS_TYPES_qemux86 += "t-x86-64"
...
Add new item checking to fix the issue.

Invoke set() to drop duplicated types

Signed-off-by: Hongxu Jia 
---
 meta/lib/oe/sstatesig.py | 17 -
 1 file changed, 16 insertions(+), 1 deletion(-)

diff --git a/meta/lib/oe/sstatesig.py b/meta/lib/oe/sstatesig.py
index 56fd953..b2ffc7e 100644
--- a/meta/lib/oe/sstatesig.py
+++ b/meta/lib/oe/sstatesig.py
@@ -64,7 +64,7 @@ def sstate_rundepfilter(siggen, fn, recipename, task, dep, 
depname, dataCache):
 def sstate_lockedsigs(d):
 sigs = {}
 types = (d.getVar("SIGGEN_LOCKEDSIGS_TYPES", True) or "").split()
-for t in types:
+for t in set(types):
 lockedsigs = (d.getVar("SIGGEN_LOCKEDSIGS_%s" % t, True) or "").split()
 for ls in lockedsigs:
 pn, task, h = ls.split(":", 2)
@@ -143,6 +143,7 @@ class 
SignatureGeneratorOEBasicHash(bb.siggen.SignatureGeneratorBasicHash):
 
 bb.plain("Writing locked sigs to %s" % sigfile)
 types = {}
+has_new_lockedsigs = False
 for k in self.runtaskdeps:
 fn = k.rsplit(".",1)[0]
 t = self.lockedhashfn[fn].split(" ")[1].split(":")[5]
@@ -151,6 +152,20 @@ class 
SignatureGeneratorOEBasicHash(bb.siggen.SignatureGeneratorBasicHash):
 types[t] = []
 types[t].append(k)
 
+if not has_new_lockedsigs:
+pn = self.lockedpnmap[fn]
+if pn not in self.lockedsigs:
+has_new_lockedsigs = True
+continue
+task = k.rsplit(".",1)[1]
+if task not in self.lockedsigs[pn]:
+has_new_lockedsigs = True
+continue
+
+if not has_new_lockedsigs:
+bb.plain("Nothing added to %s" % sigfile)
+return
+
 with open(sigfile, "a") as f:
 for t in types:
 f.write('SIGGEN_LOCKEDSIGS_%s += "\\\n' % t)
-- 
1.9.1

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

[OE-core] [PATCH 3/3] sstatesig: fix to support unincremental locked signature dump

The condition of incremental locked signature dump is an
existed locked sig file is required and it is also the
dump sig file.

But if they are not the same file or simply no locked sig
file required, it should be unincremental.

In unincremental dump situation, we should write the locked
sig file rather than append.

Signed-off-by: Hongxu Jia 
---
 meta/lib/oe/sstatesig.py | 4 
 1 file changed, 4 insertions(+)

diff --git a/meta/lib/oe/sstatesig.py b/meta/lib/oe/sstatesig.py
index b2ffc7e..ce7c960 100644
--- a/meta/lib/oe/sstatesig.py
+++ b/meta/lib/oe/sstatesig.py
@@ -93,6 +93,7 @@ class 
SignatureGeneratorOEBasicHash(bb.siggen.SignatureGeneratorBasicHash):
 self.lockedhashfn = {}
 self.machine = data.getVar("MACHINE", True)
 self.mismatch_msgs = []
+self.bbinclude = (data.getVar("BBINCLUDED", True) or "").split()
 pass
 def rundep_check(self, fn, recipename, task, dep, depname, dataCache = 
None):
 return sstate_rundepfilter(self, fn, recipename, task, dep, depname, 
dataCache)
@@ -166,6 +167,9 @@ class 
SignatureGeneratorOEBasicHash(bb.siggen.SignatureGeneratorBasicHash):
 bb.plain("Nothing added to %s" % sigfile)
 return
 
+if os.path.abspath(sigfile) not in self.bbinclude:
+open(sigfile, "w").close()
+
 with open(sigfile, "a") as f:
 for t in types:
 f.write('SIGGEN_LOCKEDSIGS_%s += "\\\n' % t)
-- 
1.9.1

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

[OE-core] [PATCH V3 0/3] sstatesig: add support to dump incremental locked signatures

How to test incrementally locked signature dump:

1) Create a new build

2) Dump locked sig file for db
$ bitbake -S none db
...
Writing locked sigs to 
/home/jiahongxu/yocto/build-20140904-yocto/locked-sigs.inc
NOTE: Tasks Summary: Attempted 0 tasks of which 0 didn't need to be rerun and 
all succeeded.
...

3) Back up locked-sigs.inc
$ cp locked-sigs.inc locked-sigs.inc.bak

4) Dump locked sig file for db again
$ bitbake -S none db
...
Writing locked sigs to 
/home/jiahongxu/yocto/build-20140904-yocto/locked-sigs.inc
NOTE: Tasks Summary: Attempted 0 tasks of which 0 didn't need to be rerun and 
all succeeded.
...

5) Compare locked-sigs.inc and locked-sigs.inc.bak to verify nothing changed
$ vimdiff locked-sigs.inc locked-sigs.inc.bak

6) Require locked-sigs.inc
vim local.conf
...
require "${TOPDIR}/locked-sigs.inc"
...

7) Incrementally dump locked sig file for world
$ bitbake -S none world
...
Writing locked sigs to 
/home/jiahongxu/yocto/build-20140904-yocto/locked-sigs.inc
NOTE: Tasks Summary: Attempted 0 tasks of which 0 didn't need to be rerun and 
all succeeded.
...

8) Compare locked-sigs.inc and locked-sigs.inc.bak to verify incrementally 
dumping
$ vimdiff locked-sigs.inc locked-sigs.inc.bak

9) Back up locked-sigs.inc
$ cp locked-sigs.inc locked-sigs.inc.bak

10) Dump for world again
$ bitbake -S none world
...
Writing locked sigs to 
/home/jiahongxu/yocto/build-20140904-yocto/locked-sigs.inc
Nothing added to /home/jiahongxu/yocto/build-20140904-yocto/locked-sigs.inc
NOTE: Tasks Summary: Attempted 0 tasks of which 0 didn't need to be rerun and 
all succeeded.
...

11) Compare locked-sigs.inc and locked-sigs.inc.bak to verify nothing changed
$ vimdiff locked-sigs.inc locked-sigs.inc.bak

//Hongxu

The following changes since commit 280b6d0011f101e7a8edabd34c265b37a2f791ed:

  sstatesig: fix overrides behaviour to remove SIGGEN_LOCKEDSIGS_i586 
(2014-09-17 22:00:26 +0100)

are available in the git repository at:

  git://git.pokylinux.org/poky-contrib hongxu/locked-sstate
  http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=hongxu/locked-sstate

Hongxu Jia (3):
  sstatesig: Only dump incremental locked signatures
  sstatesig: add new item checking for locked signature dump
  sstatesig: fix to support unincremental locked signature dump

 meta/lib/oe/sstatesig.py | 33 -
 1 file changed, 28 insertions(+), 5 deletions(-)

-- 
1.9.1

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

Re: [OE-core] [PATCH 3/9] gcc-4.9: redefine dynamic linker for aarch64

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1



On 9/16/14 8:06 AM, Kai Kang wrote:
> Redefine dynamic linker for aarch64 from /lib to /lib64.
> 
> BASELIB of aarch64 has to be defined with 'lib64', then linker file
> ld-linux-aarch64.so.1 is installed into /lib64 rather than /lib. So
> update it here too.

hmmm since the ldso name is different it can still live in /lib
and there will be ilp32 version ldso multilib as well later. can we keep
ldso in /lib ?

> 
> Signed-off-by: Kai Kang 
> ---
>  meta/recipes-devtools/gcc/gcc-4.9.inc  |  1 +
>  .../0056-redefine-dynamic-linker-for-aarch64.patch | 34 
> ++
>  2 files changed, 35 insertions(+)
>  create mode 100644 
> meta/recipes-devtools/gcc/gcc-4.9/0056-redefine-dynamic-linker-for-aarch64.patch
> 
> diff --git a/meta/recipes-devtools/gcc/gcc-4.9.inc 
> b/meta/recipes-devtools/gcc/gcc-4.9.inc
> index 25778bd..c434a45 100644
> --- a/meta/recipes-devtools/gcc/gcc-4.9.inc
> +++ b/meta/recipes-devtools/gcc/gcc-4.9.inc
> @@ -70,6 +70,7 @@ SRC_URI = "\
>  file://0053-gcc-fix-segfault-from-calling-free-on-non-malloc-d-a.patch \
>  file://0054-gcc-Makefile.in-fix-parallel-building-failure.patch \
>  file://0055-PR-rtl-optimization-61801.patch \
> +file://0056-redefine-dynamic-linker-for-aarch64.patch \
>  "
>  SRC_URI[md5sum] = "fddf71348546af523353bd43d34919c1"
>  SRC_URI[sha256sum] = 
> "d334781a124ada6f38e63b545e2a3b8c2183049515a1abab6d513f109f1d717e"
> diff --git 
> a/meta/recipes-devtools/gcc/gcc-4.9/0056-redefine-dynamic-linker-for-aarch64.patch
>  
> b/meta/recipes-devtools/gcc/gcc-4.9/0056-redefine-dynamic-linker-for-aarch64.patch
> new file mode 100644
> index 000..6933e2f
> --- /dev/null
> +++ 
> b/meta/recipes-devtools/gcc/gcc-4.9/0056-redefine-dynamic-linker-for-aarch64.patch
> @@ -0,0 +1,34 @@
> +From 8fbb60d89e569b68b13e4fd419e20640eb49cabc Mon Sep 17 00:00:00 2001
> +From: Kai Kang 
> +Date: Tue, 16 Sep 2014 16:01:31 +0800
> +Subject: [PATCH] Redefine dynamic linker for aarch64
> +
> +Redefine dynamic linker for aarch64 from /lib to /lib64.
> +
> +BASELIB of aarch64 has to be defined with 'lib64', then linker file
> +ld-linux-aarch64.so.1 is installed into /lib64 rather than /lib. So
> +update it here too.
> +
> +Upstream-Status: Pending
> +
> +Signed-off-by: Kai Kang 
> +---
> + gcc/config/aarch64/aarch64-linux.h | 2 +-
> + 1 file changed, 1 insertion(+), 1 deletion(-)
> +
> +diff --git a/gcc/config/aarch64/aarch64-linux.h 
> b/gcc/config/aarch64/aarch64-linux.h
> +index a8f0771..2a6f06d 100644
> +--- a/gcc/config/aarch64/aarch64-linux.h
>  b/gcc/config/aarch64/aarch64-linux.h
> +@@ -21,7 +21,7 @@
> + #ifndef GCC_AARCH64_LINUX_H
> + #define GCC_AARCH64_LINUX_H
> + 
> +-#define GLIBC_DYNAMIC_LINKER "/lib/ld-linux-aarch64%{mbig-endian:_be}.so.1"
> ++#define GLIBC_DYNAMIC_LINKER 
> "/lib64/ld-linux-aarch64%{mbig-endian:_be}.so.1"
> + 
> + #define CPP_SPEC "%{pthread:-D_REENTRANT}"
> + 
> +-- 
> +1.9.1
> +
> 

- -- 
- -Khem
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
Comment: GPGTools - https://gpgtools.org

iEYEARECAAYFAlQah2UACgkQuwUzVZGdMxT98wCghPbcAP/2xFgFn9Lv3Wisexa6
kHkAni6hykOqPq44VheOimbMbcimHaZD
=jpy6
-END PGP SIGNATURE-
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 9/9] perf: disable libunwind support for aarch64