Re: [OE-core] [PATCH] boost: Improve reproducibility
Thanks! Mingli, can you try this please? Alex 2018-06-15 9:44 GMT+03:00 Khem Raj : > > > On 6/1/18 12:34 PM, Alexander Kanavin wrote: >> >> On 06/01/2018 09:33 PM, Khem Raj wrote: The .s file is not generated and it does not contain any .file directives. The .o file also does not contain the path. It appears in the final .so library at linking stage. >>> >>> >>> Can you share the linker cmdline ? >> >> >> https://pastebin.com/WK9GVDfj >> >> Note that of the three assembly-generated object files, only the path to >> the first shows up in the .so - because of assembly labels I believe. >> > > Thanks for sharing this. If there is a no file directive in an object file > then linker will use whatever is specified on linker cmdline so thats what > we see, We should define FILE symbol explicitly for .S files here, for C/C++ > files compiler does that automatically. > > Other files dont make a claim in final symbol table since this one file > alone has cross referencing to symbols from other objects. > > Something like this will help > > Index: boost_1_67_0/libs/context/src/asm/make_i386_sysv_elf_gas.S > === > --- boost_1_67_0.orig/libs/context/src/asm/make_i386_sysv_elf_gas.S > +++ boost_1_67_0/libs/context/src/asm/make_i386_sysv_elf_gas.S > @@ -23,7 +23,7 @@ > * > -- > * > * * > > / > - > +.file "make_i386_sysv_elf_gas.S" > .text > .globl make_fcontext > .align 2 > Index: boost_1_67_0/libs/context/src/asm/make_x86_64_sysv_elf_gas.S > === > --- boost_1_67_0.orig/libs/context/src/asm/make_x86_64_sysv_elf_gas.S > +++ boost_1_67_0/libs/context/src/asm/make_x86_64_sysv_elf_gas.S > @@ -23,7 +23,7 @@ > * > -- > * > * * > > / > - > +.file "make_x86_64_sysv_elf_gas.S" > .text > .globl make_fcontext > .type make_fcontext,@function > > >> Alex > > -- > ___ > 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] boost: Improve reproducibility
On 6/1/18 12:34 PM, Alexander Kanavin wrote: On 06/01/2018 09:33 PM, Khem Raj wrote: The .s file is not generated and it does not contain any .file directives. The .o file also does not contain the path. It appears in the final .so library at linking stage. Can you share the linker cmdline ? https://pastebin.com/WK9GVDfj Note that of the three assembly-generated object files, only the path to the first shows up in the .so - because of assembly labels I believe. Thanks for sharing this. If there is a no file directive in an object file then linker will use whatever is specified on linker cmdline so thats what we see, We should define FILE symbol explicitly for .S files here, for C/C++ files compiler does that automatically. Other files dont make a claim in final symbol table since this one file alone has cross referencing to symbols from other objects. Something like this will help Index: boost_1_67_0/libs/context/src/asm/make_i386_sysv_elf_gas.S === --- boost_1_67_0.orig/libs/context/src/asm/make_i386_sysv_elf_gas.S +++ boost_1_67_0/libs/context/src/asm/make_i386_sysv_elf_gas.S @@ -23,7 +23,7 @@ * -- * * * / - +.file "make_i386_sysv_elf_gas.S" .text .globl make_fcontext .align 2 Index: boost_1_67_0/libs/context/src/asm/make_x86_64_sysv_elf_gas.S === --- boost_1_67_0.orig/libs/context/src/asm/make_x86_64_sysv_elf_gas.S +++ boost_1_67_0/libs/context/src/asm/make_x86_64_sysv_elf_gas.S @@ -23,7 +23,7 @@ * -- * * * / - +.file "make_x86_64_sysv_elf_gas.S" .text .globl make_fcontext .type make_fcontext,@function Alex -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] meta-toolchain: Added dnf-nativesdk into cross-development toolchain.
What you describe is exactly what image creation does (either directly through bitbake, or via 'devtool build-image'). What benefits are in running dnf by hand from command line? If the idea is to hand pick packages to add to an image, then it's better to just modify the image recipe or use 'devtool build-image' if you are developing apps in a workspace. Alex 2018-06-15 4:39 GMT+03:00 Zheng, Ruoqin : > Hi Alex: > > These packages are taken from yocto build system, and they will be installed > in your host as root file system, then you can deploy the root file system to > your embedded device. > > -- > Zheng Ruoqin > Nanjing Fujitsu Nanda Software Tech. Co., Ltd.(FNST) > ADDR.: No.6 Wenzhu Road, Software Avenue, >Nanjing, 210012, China > MAIL : zhengrq.f...@cn.fujistu.com > > > -Original Message- > From: Alexander Kanavin [mailto:alex.kana...@gmail.com] > Sent: Thursday, June 14, 2018 3:03 PM > To: Zheng, Ruoqin/郑 若钦 > Cc: Burton, Ross ; OE-core > > Subject: Re: [OE-core] [PATCH] meta-toolchain: Added dnf-nativesdk into > cross-development toolchain. > > 2018-06-14 6:38 GMT+03:00 Zheng, Ruoqin : >> I submitted this patch aim to use dnf out of Yocto build system to manage >> packages. > > Please explain this in detail. Where are the packages taken from, and where > are they installed? > > Alex > > > > -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH v3 3/5] tune-cortexa35: add tunes for ARM Cortex-A35
https://developer.arm.com/products/processors/cortex-a/cortex-a35
Signed-off-by: Randy Li
---
meta/conf/machine/include/tune-cortexa35.inc | 15 +++
1 file changed, 15 insertions(+)
create mode 100644 meta/conf/machine/include/tune-cortexa35.inc
diff --git a/meta/conf/machine/include/tune-cortexa35.inc
b/meta/conf/machine/include/tune-cortexa35.inc
new file mode 100644
index 00..535a8aef15
--- /dev/null
+++ b/meta/conf/machine/include/tune-cortexa35.inc
@@ -0,0 +1,15 @@
+DEFAULTTUNE ?= "cortexa35"
+
+require conf/machine/include/arm/arch-armv8a.inc
+
+TUNEVALID[cortexa35] = "Enable Cortex-A35 specific processor optimizations"
+TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'cortexa35', '
-mcpu=cortex-a35', '', d)}"
+
+# Little Endian base configs
+AVAILTUNES += "cortexa35 cortexa35-crypto"
+ARMPKGARCH_tune-cortexa35 = "cortexa35"
+ARMPKGARCH_tune-cortexa35-crypto = "cortexa35"
+TUNE_FEATURES_tune-cortexa35 = "${TUNE_FEATURES_tune-armv8a-crc}
cortexa35"
+TUNE_FEATURES_tune-cortexa35-crypto =
"${TUNE_FEATURES_tune-armv8a-crc-crypto} cortexa35"
+PACKAGE_EXTRA_ARCHS_tune-cortexa35 =
"${PACKAGE_EXTRA_ARCHS_tune-armv8a-crc} cortexa35"
+PACKAGE_EXTRA_ARCHS_tune-cortexa35-crypto =
"${PACKAGE_EXTRA_ARCHS_tune-armv8a-crc-crypto} cortexa35 cortexa35-crypto"
--
2.14.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH v3 2/5] tune-cortexa32: add tunes for ARM Cortex-A32
https://developer.arm.com/products/processors/cortex-a/cortex-a32
Signed-off-by: Randy Li
---
meta/conf/machine/include/tune-cortexa32.inc | 15 +++
1 file changed, 15 insertions(+)
create mode 100644 meta/conf/machine/include/tune-cortexa32.inc
diff --git a/meta/conf/machine/include/tune-cortexa32.inc
b/meta/conf/machine/include/tune-cortexa32.inc
new file mode 100644
index 00..22f303fae9
--- /dev/null
+++ b/meta/conf/machine/include/tune-cortexa32.inc
@@ -0,0 +1,15 @@
+DEFAULTTUNE ?= "cortexa32"
+
+require conf/machine/include/arm/arch-armv8a.inc
+
+TUNEVALID[cortexa32] = "Enable Cortex-A32 specific processor optimizations"
+TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'cortexa32', '
-mcpu=cortex-a32', '', d)}"
+
+# Little Endian base configs
+AVAILTUNES += "cortexa32 cortexa32-crypto"
+ARMPKGARCH_tune-cortexa32 = "cortexa32"
+ARMPKGARCH_tune-cortexa32-crypto = "cortexa32"
+TUNE_FEATURES_tune-cortexa32 = "${TUNE_FEATURES_tune-armv8a-crc}
cortexa32"
+TUNE_FEATURES_tune-cortexa32-crypto =
"${TUNE_FEATURES_tune-armv8a-crc-crypto} cortexa32"
+PACKAGE_EXTRA_ARCHS_tune-cortexa32 =
"${PACKAGE_EXTRA_ARCHS_tune-armv8a-crc} cortexa32"
+PACKAGE_EXTRA_ARCHS_tune-cortexa32-crypto =
"${PACKAGE_EXTRA_ARCHS_tune-armv8a-crc-crypto} cortexa32 cortexa32-crypto"
--
2.14.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH v3 4/5] tune-cortexa53: add tunes for ARM Cortex-A53
It looks that the Cryptography engine is mandatory in this
platform.
https://developer.arm.com/products/processors/cortex-a/cortex-a53
Signed-off-by: Randy Li
---
meta/conf/machine/include/tune-cortexa53.inc | 15 +++
1 file changed, 15 insertions(+)
create mode 100644 meta/conf/machine/include/tune-cortexa53.inc
diff --git a/meta/conf/machine/include/tune-cortexa53.inc
b/meta/conf/machine/include/tune-cortexa53.inc
new file mode 100644
index 00..050a735d8e
--- /dev/null
+++ b/meta/conf/machine/include/tune-cortexa53.inc
@@ -0,0 +1,15 @@
+DEFAULTTUNE ?= "cortexa53"
+
+require conf/machine/include/arm/arch-armv8a.inc
+
+TUNEVALID[cortexa53] = "Enable Cortex-A53 specific processor optimizations"
+TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'cortexa53', '
-mcpu=cortex-a53', '', d)}"
+
+# Little Endian base configs
+AVAILTUNES += "cortexa53 cortexa53-crypto"
+ARMPKGARCH_tune-cortexa53 = "cortexa53"
+ARMPKGARCH_tune-cortexa53-crypto = "cortexa53"
+TUNE_FEATURES_tune-cortexa53 = "${TUNE_FEATURES_tune-armv8a-crc}
cortexa53"
+TUNE_FEATURES_tune-cortexa53-crypto =
"${TUNE_FEATURES_tune-armv8a-crc-crypto} cortexa53"
+PACKAGE_EXTRA_ARCHS_tune-cortexa53 =
"${PACKAGE_EXTRA_ARCHS_tune-armv8a-crc} cortexa53"
+PACKAGE_EXTRA_ARCHS_tune-cortexa53-crypto =
"${PACKAGE_EXTRA_ARCHS_tune-armv8a-crc-crypto} cortexa53 cortexa53-crypto"
--
2.14.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH v3 5/5] tune-cortexa72: add tunes for ARM Cortex-A72
It looks that the Cryptography engine is mandatory in this
platform.
https://developer.arm.com/products/processors/cortex-a/cortex-a72
Signed-off-by: Randy Li
---
meta/conf/machine/include/tune-cortexa72.inc | 12
1 file changed, 12 insertions(+)
create mode 100644 meta/conf/machine/include/tune-cortexa72.inc
diff --git a/meta/conf/machine/include/tune-cortexa72.inc
b/meta/conf/machine/include/tune-cortexa72.inc
new file mode 100644
index 00..8055492b8e
--- /dev/null
+++ b/meta/conf/machine/include/tune-cortexa72.inc
@@ -0,0 +1,12 @@
+DEFAULTTUNE ?= "cortexa72"
+
+require conf/machine/include/arm/arch-armv8a.inc
+
+TUNEVALID[cortexa72] = "Enable Cortex-A72 specific processor optimizations"
+TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'cortexa72', '
-mcpu=cortex-a72', '', d)}"
+
+# Little Endian base configs
+AVAILTUNES += "cortexa72"
+ARMPKGARCH_tune-cortexa72 = "cortexa72"
+TUNE_FEATURES_tune-cortexa72 =
"${TUNE_FEATURES_tune-armv8a-crc-crypto} cortexa72"
+PACKAGE_EXTRA_ARCHS_tune-cortexa72=
"${PACKAGE_EXTRA_ARCHS_tune-armv8a-crc-crypto} cortexa72"
--
2.14.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH v3 1/5] arch-armv8a.inc: add tune include for armv8
There are some addtional instructions apart from bare armv8,
also there is armv8.1, armv8.2.
Most the processor would support crc, except X-gene 1.
Signed-off-by: Randy Li
---
meta/conf/machine/include/arm/arch-armv8.inc | 1 -
meta/conf/machine/include/arm/arch-armv8a.inc | 28 +++
2 files changed, 28 insertions(+), 1 deletion(-)
delete mode 100644 meta/conf/machine/include/arm/arch-armv8.inc
create mode 100644 meta/conf/machine/include/arm/arch-armv8a.inc
diff --git a/meta/conf/machine/include/arm/arch-armv8.inc
b/meta/conf/machine/include/arm/arch-armv8.inc
deleted file mode 100644
index 5e832fae6d..00
--- a/meta/conf/machine/include/arm/arch-armv8.inc
+++ /dev/null
@@ -1 +0,0 @@
-require conf/machine/include/arm/arch-arm64.inc
diff --git a/meta/conf/machine/include/arm/arch-armv8a.inc
b/meta/conf/machine/include/arm/arch-armv8a.inc
new file mode 100644
index 00..323d0d7f0f
--- /dev/null
+++ b/meta/conf/machine/include/arm/arch-armv8a.inc
@@ -0,0 +1,28 @@
+DEFAULTTUNE ?= "armv8a-crc"
+
+TUNEVALID[armv8a] = "Enable instructions for ARMv8-a"
+TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'armv8a', '
-march=armv8-a', '', d)}"
+TUNEVALID[simd] = "Enable instructions for ARMv8-a Advanced SIMD and
floating-point"
+TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'simd', '+simd', '', d)}"
+TUNEVALID[crc] = "Enable instructions for ARMv8-a Cyclic Redundancy Check
(CRC)"
+TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'crc', '+crc', '', d)}"
+TUNEVALID[crypto] = "Enable instructions for ARMv8-a cryptographic"
+TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'crypto', '+crypto', '',
d)}"
+MACHINEOVERRIDES =. "${@bb.utils.contains('TUNE_FEATURES', 'armv8a',
'armv8a:', '' ,d)}"
+
+require conf/machine/include/arm/arch-arm64.inc
+
+# Little Endian base configs
+AVAILTUNES += "armv8a armv8a-crc armv8a-crc-crypto armv8a-crypto"
+ARMPKGARCH_tune-armv8a?= "armv8a"
+ARMPKGARCH_tune-armv8a-crc?= "armv8a"
+ARMPKGARCH_tune-armv8a-crypto ?= "armv8a"
+ARMPKGARCH_tune-armv8a-crc-crypto ?= "armv8a"
+TUNE_FEATURES_tune-armv8a = "aarch64 armv8a simd"
+TUNE_FEATURES_tune-armv8a-crc = "${TUNE_FEATURES_tune-armv8a} crc"
+TUNE_FEATURES_tune-armv8a-crypto = "${TUNE_FEATURES_tune-armv8a}
crypto"
+TUNE_FEATURES_tune-armv8a-crc-crypto = "${TUNE_FEATURES_tune-armv8a-crc}
crypto"
+PACKAGE_EXTRA_ARCHS_tune-armv8a= "aarch64 armv8a simd"
+PACKAGE_EXTRA_ARCHS_tune-armv8a-crc=
"${PACKAGE_EXTRA_ARCHS_tune-armv8a} crc"
+PACKAGE_EXTRA_ARCHS_tune-armv8a-crypto =
"${PACKAGE_EXTRA_ARCHS_tune-armv8a} crypto"
+PACKAGE_EXTRA_ARCHS_tune-armv8a-crc-crypto =
"${PACKAGE_EXTRA_ARCHS_tune-armv8a-crc} crypto"
--
2.14.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH v3 0/5] Add tune for ARMv8 and some cortex processors
I mistake some thing wrong in the previous version, I have verified this version and it works. I have not found a way to support big little. Randy Li (5): arch-armv8a.inc: add tune include for armv8 tune-cortexa32: add tunes for ARM Cortex-A32 tune-cortexa35: add tunes for ARM Cortex-A35 tune-cortexa53: add tunes for ARM Cortex-A53 tune-cortexa72: add tunes for ARM Cortex-A72 meta/conf/machine/include/arm/arch-armv8.inc | 1 - meta/conf/machine/include/arm/arch-armv8a.inc | 28 +++ meta/conf/machine/include/tune-cortexa32.inc | 15 ++ meta/conf/machine/include/tune-cortexa35.inc | 15 ++ meta/conf/machine/include/tune-cortexa53.inc | 15 ++ meta/conf/machine/include/tune-cortexa72.inc | 12 6 files changed, 85 insertions(+), 1 deletion(-) delete mode 100644 meta/conf/machine/include/arm/arch-armv8.inc create mode 100644 meta/conf/machine/include/arm/arch-armv8a.inc create mode 100644 meta/conf/machine/include/tune-cortexa32.inc create mode 100644 meta/conf/machine/include/tune-cortexa35.inc create mode 100644 meta/conf/machine/include/tune-cortexa53.inc create mode 100644 meta/conf/machine/include/tune-cortexa72.inc -- 2.14.4 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] meta-toolchain: Added dnf-nativesdk into cross-development toolchain.
Hi Alex: These packages are taken from yocto build system, and they will be installed in your host as root file system, then you can deploy the root file system to your embedded device. -- Zheng Ruoqin Nanjing Fujitsu Nanda Software Tech. Co., Ltd.(FNST) ADDR.: No.6 Wenzhu Road, Software Avenue, Nanjing, 210012, China MAIL : zhengrq.f...@cn.fujistu.com -Original Message- From: Alexander Kanavin [mailto:alex.kana...@gmail.com] Sent: Thursday, June 14, 2018 3:03 PM To: Zheng, Ruoqin/郑 若钦 Cc: Burton, Ross ; OE-core Subject: Re: [OE-core] [PATCH] meta-toolchain: Added dnf-nativesdk into cross-development toolchain. 2018-06-14 6:38 GMT+03:00 Zheng, Ruoqin : > I submitted this patch aim to use dnf out of Yocto build system to manage > packages. Please explain this in detail. Where are the packages taken from, and where are they installed? Alex -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 4/4] recipes-kernel/linux: Add RISC-V support
On Thu, Jun 14, 2018 at 3:45 PM, Alistair Francis
wrote:
> Signed-off-by: Alistair Francis
> ---
> meta/recipes-kernel/linux/linux-yocto.inc | 4
> meta/recipes-kernel/linux/linux-yocto_4.15.bb | 5 -
> 2 files changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/meta/recipes-kernel/linux/linux-yocto.inc
> b/meta/recipes-kernel/linux/linux-yocto.inc
> index 95ec2a2b41..70a13cdd1e 100644
> --- a/meta/recipes-kernel/linux/linux-yocto.inc
> +++ b/meta/recipes-kernel/linux/linux-yocto.inc
> @@ -26,6 +26,10 @@ DEPENDS_append_nios2 = " libgcc"
> KERNEL_CC_append_nios2 = " ${TOOLCHAIN_OPTIONS}"
> KERNEL_LD_append_nios2 = " ${TOOLCHAIN_OPTIONS}"
>
> +DEPENDS_append_riscv64 = " libgcc"
> +KERNEL_CC_append_riscv64 = " ${TOOLCHAIN_OPTIONS}
> ${SECURITY_NOPIE_CFLAGS}"
> +KERNEL_LD_append_riscv64 = " -no-pie"
> +
> KERNEL_FEATURES_append_qemuall=" features/debug/printk.scc"
>
> # A KMACHINE is the mapping of a yocto $MACHINE to what is built
> diff --git a/meta/recipes-kernel/linux/linux-yocto_4.15.bb
> b/meta/recipes-kernel/linux/linux-yocto_4.15.bb
> index 693670c613..4ea368a011 100644
> --- a/meta/recipes-kernel/linux/linux-yocto_4.15.bb
> +++ b/meta/recipes-kernel/linux/linux-yocto_4.15.bb
> @@ -36,7 +36,10 @@ KCONF_BSP_AUDIT_LEVEL = "2"
>
> KERNEL_DEVICETREE_qemuarm = "versatile-pb.dtb"
>
> -COMPATIBLE_MACHINE = "qemuarm|qemuarm64|qemux86|
> qemuppc|qemumips|qemumips64|qemux86-64"
> +KBUILD_DEFCONFIG_qemuriscv64 = "defconfig"
> +KCONFIG_MODE_qemuriscv64 = "--alldefconfig"
>
This doesn't belong in linux-yocto.
We use defined BSP and configuration fraagments, not in-tree defconfigs
I'm happy to add a BSP definition to the kernel-cache, but this isn't the
way to add configuration support for the linux-yocto trees
Cheers,
Bruce
> +
> +COMPATIBLE_MACHINE = "qemuarm|qemuarm64|qemux86|
> qemuppc|qemumips|qemumips64|qemux86-64|qemurisc532|qemuriscv64"
>
> # Functionality flags
> KERNEL_EXTRA_FEATURES ?= "features/netfilter/netfilter.scc"
> --
> 2.17.1
>
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
--
"Thou shalt not follow the NULL pointer, for chaos and madness await thee
at its end"
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/1] db: disable the ARM assembler mutex code
On Thu, Jun 14, 2018 at 2:48 PM, Khem Raj wrote:
> On Thu, Jun 14, 2018 at 1:01 PM Andre McCurdy wrote:
>> On Thu, Jun 14, 2018 at 12:24 PM, Khem Raj wrote:
>> > On Thu, Jun 14, 2018 at 12:12 PM Andre McCurdy
>> > wrote:
>> >>
>> >> On Thu, Jun 14, 2018 at 9:40 AM, Khem Raj wrote:
>> >> > On 6/14/18 5:10 AM, Herve Jourdain wrote:
>> >> >> Hi,
>> >> >>
>> >> >> I believe I solved that same problem by just adding, in the case of
>> >> >> armv8
>> >> >> (which I believe may be the new architecture you're referring to):
>> >> >> MUTEX_armv8 = ""
>> >> >> This way, it allows previous versions to work just like they did
>> >> >> before,
>> >> >> without having to disable ARM assembler mutex code for architectures
>> >> >> that
>> >> >> support it correctly - up to armv7ve I believe.
>> >> >> Of course, we might need to also have a good definition for armv8,
>> >> >> which is
>> >> >> the object of another thread.
>> >> >
>> >> > right thats a better approach.
>> >>
>> >> SWP is not guaranteed to work on SMP systems... and even if it does,
>> >> performance is likely to be worse than the pthreads version (which can
>> >> take advantage of the newer instructions).
>> >>
>> >>
>> >> https://community.arm.com/processors/b/blog/posts/locks-swps-and-two-smoking-barriers
>> >>
>> >> In general, use of hand optimised assembler mutex implementations in
>> >> user space isn't something to be encouraged - use pthreads (or maybe a
>> >> gcc intrinsic) instead.
>> >>
>> >
>> > question is about disabling it on old arm machines, do we have data
>> > where
>> > we know that other sync methods without swp works better on armv5 and
>> > lower ?
>>
>> On armv5 and below a hand optimised implementation using SWP is likely
>> to be faster than pthreads. No one is suggesting otherwise.
>>
>> On SMP (highly likely nowadays for armv7 and above), SWP simply might
>> not work (aside from the fact that if it does work, it's likely to be
>> slower than pthreads). It's not really a question of performance
>> there, so the proposal to only disable SWP for armv8 doesn't seem like
>> a safe solution.
>
> Suggestion is not to just do it for armv8 but
> To keep it there where its beneficial
You can always argue that micro optimisations are beneficial. The
question is whether they make a big enough difference in some real
world use case to be worth the maintenance effort.
>> Using pthreads unconditionally is safe and easy. Unless you can prove
>> that hand optimised SWP is really a big win for armv5 (is anyone
>> really running a performance critical database on an armv5 system?)
>> why not keep the recipe simple and use pthreads everywhere?
>>
>> >> I think the original patch is good.
>> >>
>> >> >> Cheers,
>> >> >> Herve
>> >> >>
>> >> >> -Original Message-
>> >> >> From: openembedded-core-boun...@lists.openembedded.org
>> >> >> [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf
>> >> >> Of
>> >> >> Ovidiu Panait
>> >> >> Sent: jeudi 14 juin 2018 13:55
>> >> >> To: openembedded-core@lists.openembedded.org
>> >> >> Subject: [OE-core] [PATCH 1/1] db: disable the ARM assembler mutex
>> >> >> code
>> >> >>
>> >> >> The swpb in macro MUTEX_SET will cause "undefined instruction" error
>> >> >> on the
>> >> >> new arm arches which don't support this assembly instruction any
>> >> >> more. If
>> >> >> use ldrex/strex to replace swpb, the old arm arches don't support
>> >> >> them. So
>> >> >> to avoid this issue, just disable the ARM assembler mutex code, and
>> >> >> use the
>> >> >> default pthreads mutex.
>> >> >>
>> >> >> Signed-off-by: Li Zhou
>> >> >> Signed-off-by: Catalin Enache
>> >> >> Signed-off-by: Ovidiu Panait
>> >> >> ---
>> >> >> meta/recipes-support/db/db_5.3.28.bb | 13 +
>> >> >> 1 file changed, 1 insertion(+), 12 deletions(-)
>> >> >>
>> >> >> diff --git a/meta/recipes-support/db/db_5.3.28.bb
>> >> >> b/meta/recipes-support/db/db_5.3.28.bb
>> >> >> index 093ee44909..15b4155a29 100644
>> >> >> --- a/meta/recipes-support/db/db_5.3.28.bb
>> >> >> +++ b/meta/recipes-support/db/db_5.3.28.bb
>> >> >> @@ -59,18 +59,7 @@ FILES_SOLIBSDEV = "${libdir}/libdb.so
>> >> >> ${libdir}/libdb_cxx.so"
>> >> >> # All the --disable-* options replace --enable-smallbuild, which
>> >> >> breaks a
>> >> >> bunch of stuff (eg. postfix) DB5_CONFIG ?= "--enable-o_direct
>> >> >> --disable-cryptography --disable-queue --disable-replication
>> >> >> --disable-verify --disable-compat185 --disable-sql"
>> >> >>
>> >> >> -EXTRA_OECONF = "${DB5_CONFIG} --enable-shared --enable-cxx
>> >> >> --with-sysroot"
>> >> >> -
>> >> >> -# Override the MUTEX setting here, the POSIX library is -# the
>> >> >> default -
>> >> >> "POSIX/pthreads/library".
>> >> >> -# Don't ignore the nice SWP instruction on the ARM:
>> >> >> -# These enable the ARM assembler mutex code, this won't -# work
>> >> >> with thumb
>> >> >> compilation...
>> >> >> -ARM_MUTEX = "--with-mutex=ARM/gcc-assembly"
>> >> >> -MUTEX = ""
>> >> >> -MUTEX_arm = "${
Re: [OE-core] [PATCH 1/1] db: disable the ARM assembler mutex code
On Thu, Jun 14, 2018 at 1:01 PM Andre McCurdy wrote:
> On Thu, Jun 14, 2018 at 12:24 PM, Khem Raj wrote:
> > On Thu, Jun 14, 2018 at 12:12 PM Andre McCurdy
> wrote:
> >>
> >> On Thu, Jun 14, 2018 at 9:40 AM, Khem Raj wrote:
> >> > On 6/14/18 5:10 AM, Herve Jourdain wrote:
> >> >> Hi,
> >> >>
> >> >> I believe I solved that same problem by just adding, in the case of
> armv8
> >> >> (which I believe may be the new architecture you're referring to):
> >> >> MUTEX_armv8 = ""
> >> >> This way, it allows previous versions to work just like they did
> before,
> >> >> without having to disable ARM assembler mutex code for architectures
> that
> >> >> support it correctly - up to armv7ve I believe.
> >> >> Of course, we might need to also have a good definition for armv8,
> which is
> >> >> the object of another thread.
> >> >
> >> > right thats a better approach.
> >>
> >> SWP is not guaranteed to work on SMP systems... and even if it does,
> >> performance is likely to be worse than the pthreads version (which can
> >> take advantage of the newer instructions).
> >>
> >>
> https://community.arm.com/processors/b/blog/posts/locks-swps-and-two-smoking-barriers
> >>
> >> In general, use of hand optimised assembler mutex implementations in
> >> user space isn't something to be encouraged - use pthreads (or maybe a
> >> gcc intrinsic) instead.
> >>
> >
> > question is about disabling it on old arm machines, do we have data where
> > we know that other sync methods without swp works better on armv5 and
> lower ?
>
> On armv5 and below a hand optimised implementation using SWP is likely
> to be faster than pthreads. No one is suggesting otherwise.
>
> On SMP (highly likely nowadays for armv7 and above), SWP simply might
> not work (aside from the fact that if it does work, it's likely to be
> slower than pthreads). It's not really a question of performance
> there, so the proposal to only disable SWP for armv8 doesn't seem like
> a safe solution.
>
Suggestion is not to just do it for armv8 but
To keep it there where its beneficial
>
> Using pthreads unconditionally is safe and easy. Unless you can prove
> that hand optimised SWP is really a big win for armv5 (is anyone
> really running a performance critical database on an armv5 system?)
> why not keep the recipe simple and use pthreads everywhere?
>
> >> I think the original patch is good.
> >>
> >> >> Cheers,
> >> >> Herve
> >> >>
> >> >> -Original Message-
> >> >> From: openembedded-core-boun...@lists.openembedded.org
> >> >> [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf
> Of
> >> >> Ovidiu Panait
> >> >> Sent: jeudi 14 juin 2018 13:55
> >> >> To: openembedded-core@lists.openembedded.org
> >> >> Subject: [OE-core] [PATCH 1/1] db: disable the ARM assembler mutex
> code
> >> >>
> >> >> The swpb in macro MUTEX_SET will cause "undefined instruction" error
> on the
> >> >> new arm arches which don't support this assembly instruction any
> more. If
> >> >> use ldrex/strex to replace swpb, the old arm arches don't support
> them. So
> >> >> to avoid this issue, just disable the ARM assembler mutex code, and
> use the
> >> >> default pthreads mutex.
> >> >>
> >> >> Signed-off-by: Li Zhou
> >> >> Signed-off-by: Catalin Enache
> >> >> Signed-off-by: Ovidiu Panait
> >> >> ---
> >> >> meta/recipes-support/db/db_5.3.28.bb | 13 +
> >> >> 1 file changed, 1 insertion(+), 12 deletions(-)
> >> >>
> >> >> diff --git a/meta/recipes-support/db/db_5.3.28.bb
> >> >> b/meta/recipes-support/db/db_5.3.28.bb
> >> >> index 093ee44909..15b4155a29 100644
> >> >> --- a/meta/recipes-support/db/db_5.3.28.bb
> >> >> +++ b/meta/recipes-support/db/db_5.3.28.bb
> >> >> @@ -59,18 +59,7 @@ FILES_SOLIBSDEV = "${libdir}/libdb.so
> >> >> ${libdir}/libdb_cxx.so"
> >> >> # All the --disable-* options replace --enable-smallbuild, which
> breaks a
> >> >> bunch of stuff (eg. postfix) DB5_CONFIG ?= "--enable-o_direct
> >> >> --disable-cryptography --disable-queue --disable-replication
> >> >> --disable-verify --disable-compat185 --disable-sql"
> >> >>
> >> >> -EXTRA_OECONF = "${DB5_CONFIG} --enable-shared --enable-cxx
> --with-sysroot"
> >> >> -
> >> >> -# Override the MUTEX setting here, the POSIX library is -# the
> default -
> >> >> "POSIX/pthreads/library".
> >> >> -# Don't ignore the nice SWP instruction on the ARM:
> >> >> -# These enable the ARM assembler mutex code, this won't -# work
> with thumb
> >> >> compilation...
> >> >> -ARM_MUTEX = "--with-mutex=ARM/gcc-assembly"
> >> >> -MUTEX = ""
> >> >> -MUTEX_arm = "${ARM_MUTEX}"
> >> >> -MUTEX_armeb = "${ARM_MUTEX}"
> >> >> -EXTRA_OECONF += "${MUTEX} STRIP=true"
> >> >> +EXTRA_OECONF = "${DB5_CONFIG} --enable-shared --enable-cxx
> --with-sysroot
> >> >> STRIP=true"
> >> >> EXTRA_OEMAKE += "LIBTOOL='./${HOST_SYS}-libtool'"
> >> >>
> >> >> EXTRA_AUTORECONF += "--exclude=autoheader -I ${S}/dist/aclocal
> >> >> -I${S}/dist/aclocal_java"
> >> >> --
> >> >> 2.17.1
> >> >>
> >> >> --
> >> >> __
Re: [OE-core] [PATCH 1/4] recipes-devtools/qemu: Add RISC-V support
> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org
> [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of
> Alistair Francis
> Sent: den 14 juni 2018 21:43
> To: openembedded-core@lists.openembedded.org
> Subject: [OE-core] [PATCH 1/4] recipes-devtools/qemu: Add RISC-V
> support
>
> Signed-off-by: Alistair Francis
> ---
> 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 faaea781cd..d1543b81f9 100644
> --- a/meta/recipes-devtools/qemu/qemu.inc
> +++ b/meta/recipes-devtools/qemu/qemu.inc
> @@ -9,7 +9,7 @@ inherit autotools pkgconfig bluetooth
> BBCLASSEXTEND = "native nativesdk"
>
> # QEMU_TARGETS is overridable variable
> -QEMU_TARGETS ?= "arm aarch64 i386 mips mipsel mips64 mips64el ppc sh4 x86_64"
> +QEMU_TARGETS ?= "arm aarch64 i386 mips mipsel mips64 mips64el ppc sh4 x86_64
> riscv32 riscv64"
Might as well keep the targets logically sorted:
QEMU_TARGETS ?= "arm aarch64 i386 mips mipsel mips64 mips64el ppc riscv32
riscv64 sh4 x86_64"
>
> EXTRA_OECONF = " \
> --prefix=${prefix} \
> --
> 2.17.1
//Peter
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 3/4] recipes-support/nspr: Add RISC-V support
The patch file needs Upstream-Status in addition to SOB.
(also why is patchtest not reacting to patches anymore?)
Alex
2018-06-14 22:45 GMT+03:00 Alistair Francis :
> Signed-off-by: Alistair Francis
> ---
> .../0003-Add-riscv-architecture-support.patch | 103 ++
> meta/recipes-support/nspr/nspr_4.19.bb| 1 +
> 2 files changed, 104 insertions(+)
> create mode 100644
> meta/recipes-support/nspr/nspr/0003-Add-riscv-architecture-support.patch
>
> diff --git
> a/meta/recipes-support/nspr/nspr/0003-Add-riscv-architecture-support.patch
> b/meta/recipes-support/nspr/nspr/0003-Add-riscv-architecture-support.patch
> new file mode 100644
> index 00..14911440bd
> --- /dev/null
> +++ b/meta/recipes-support/nspr/nspr/0003-Add-riscv-architecture-support.patch
> @@ -0,0 +1,103 @@
> +From ff3d77742bd3b0272c48ff7472a45e9c537709f2 Mon Sep 17 00:00:00 2001
> +From: Khem Raj
> +Date: Wed, 4 Oct 2017 11:55:10 -0700
> +Subject: [PATCH] Add riscv architecture support
> +
> +Signed-off-by: Khem Raj
> +---
> + pr/include/md/_linux.cfg | 46 ++
> + pr/include/md/_linux.h | 14 ++
> + 2 files changed, 60 insertions(+)
> +
> +diff --git a/pr/include/md/_linux.cfg b/pr/include/md/_linux.cfg
> +index 31296a8..d0dde57 100644
> +--- a/pr/include/md/_linux.cfg
> b/pr/include/md/_linux.cfg
> +@@ -360,6 +360,52 @@
> + #define PR_BYTES_PER_WORD_LOG2 2
> + #define PR_BYTES_PER_DWORD_LOG2 3
> +
> ++#elif defined(__riscv) && __riscv_xlen == 64
> ++
> ++#undefIS_BIG_ENDIAN
> ++#define IS_LITTLE_ENDIAN 1
> ++#define IS_64
> ++
> ++#define PR_BYTES_PER_BYTE 1
> ++#define PR_BYTES_PER_SHORT 2
> ++#define PR_BYTES_PER_INT4
> ++#define PR_BYTES_PER_INT64 8
> ++#define PR_BYTES_PER_LONG 8
> ++#define PR_BYTES_PER_FLOAT 4
> ++#define PR_BYTES_PER_DOUBLE 8
> ++#define PR_BYTES_PER_WORD 8
> ++#define PR_BYTES_PER_DWORD 8
> ++
> ++#define PR_BITS_PER_BYTE8
> ++#define PR_BITS_PER_SHORT 16
> ++#define PR_BITS_PER_INT 32
> ++#define PR_BITS_PER_INT64 64
> ++#define PR_BITS_PER_LONG64
> ++#define PR_BITS_PER_FLOAT 32
> ++#define PR_BITS_PER_DOUBLE 64
> ++#define PR_BITS_PER_WORD64
> ++
> ++#define PR_BITS_PER_BYTE_LOG2 3
> ++#define PR_BITS_PER_SHORT_LOG2 4
> ++#define PR_BITS_PER_INT_LOG25
> ++#define PR_BITS_PER_INT64_LOG2 6
> ++#define PR_BITS_PER_LONG_LOG2 6
> ++#define PR_BITS_PER_FLOAT_LOG2 5
> ++#define PR_BITS_PER_DOUBLE_LOG2 6
> ++#define PR_BITS_PER_WORD_LOG2 6
> ++
> ++#define PR_ALIGN_OF_SHORT 2
> ++#define PR_ALIGN_OF_INT 4
> ++#define PR_ALIGN_OF_INT64 8
> ++#define PR_ALIGN_OF_LONG8
> ++#define PR_ALIGN_OF_FLOAT 4
> ++#define PR_ALIGN_OF_DOUBLE 8
> ++#define PR_ALIGN_OF_POINTER 8
> ++#define PR_ALIGN_OF_WORD8
> ++
> ++#define PR_BYTES_PER_WORD_LOG2 3
> ++#define PR_BYTES_PER_DWORD_LOG2 3
> ++
> + #elif defined(__sparc__) && defined (__arch64__)
> +
> + #undefIS_LITTLE_ENDIAN
> +diff --git a/pr/include/md/_linux.h b/pr/include/md/_linux.h
> +index 551918f..3a3cc2e 100644
> +--- a/pr/include/md/_linux.h
> b/pr/include/md/_linux.h
> +@@ -31,6 +31,8 @@
> + #define _PR_SI_ARCHITECTURE "x86-64"
> + #elif defined(__mc68000__)
> + #define _PR_SI_ARCHITECTURE "m68k"
> ++#elif defined(__riscv) && __riscv_xlen == 64
> ++#define _PR_SI_ARCHITECTURE "rv64"
> + #elif defined(__sparc__) && defined(__arch64__)
> + #define _PR_SI_ARCHITECTURE "sparc64"
> + #elif defined(__sparc__)
> +@@ -151,6 +153,18 @@ extern PRInt32 _PR_x86_64_AtomicSet(PRInt32 *val,
> PRInt32 newval);
> + #endif
> + #endif
> +
> ++#if defined(__riscv)
> ++#if defined(__GNUC__)
> ++/* Use GCC built-in functions */
> ++#define _PR_HAVE_ATOMIC_OPS
> ++#define _MD_INIT_ATOMIC()
> ++#define _MD_ATOMIC_INCREMENT(ptr) __sync_add_and_fetch(ptr, 1)
> ++#define _MD_ATOMIC_DECREMENT(ptr) __sync_sub_and_fetch(ptr, 1)
> ++#define _MD_ATOMIC_ADD(ptr, i) __sync_add_and_fetch(ptr, i)
> ++#define _MD_ATOMIC_SET(ptr, nv) __sync_lock_test_and_set(ptr, nv)
> ++#endif
> ++#endif
> ++
> + #if defined(__powerpc__) && !defined(__powerpc64__)
> + #define _PR_HAVE_ATOMIC_OPS
> + #define _MD_INIT_ATOMIC()
> +--
> +2.14.2
> +
> diff --git a/meta/recipes-support/nspr/nspr_4.19.bb
> b/meta/recipes-support/nspr/nspr_4.19.bb
> index de2c87131f..5c37509b1b 100644
> --- a/meta/recipes-support/nspr/nspr_4.19.bb
> +++ b/meta/recipes-support/nspr/nspr_4.19.bb
> @@ -11,6 +11,7 @@ SRC_URI =
> "http://ftp.mozilla.org/pub/nspr/releases/v${PV}/src/nspr-${PV}.tar.gz
> file://remove-srcdir-from-configure-in.patch \
> file://0002-Add-nios2-support.patch \
> file://0001-md-Fix-build-with-musl.patch \
> + file://0003-Add-riscv-architecture-support.patch \
> file://nspr.pc.in \
> "
>
> --
> 2.17.1
>
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listi
Re: [OE-core] [PATCH 2/4] recipes-extended/psmisc: Don't exclude autopoint for RISCV
Don't exclude why? Needs to be in recipe comment.
Alex
2018-06-14 22:45 GMT+03:00 Alistair Francis :
> Signed-off-by: Alistair Francis
> ---
> meta/recipes-extended/psmisc/psmisc.inc | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/meta/recipes-extended/psmisc/psmisc.inc
> b/meta/recipes-extended/psmisc/psmisc.inc
> index 82ef947709..73b4c56f69 100644
> --- a/meta/recipes-extended/psmisc/psmisc.inc
> +++ b/meta/recipes-extended/psmisc/psmisc.inc
> @@ -19,7 +19,9 @@ inherit autotools gettext
> # Upstream has a custom autogen.sh which invokes po/update-potfiles as they
> # don't ship a po/POTFILES.in (which is silly). Without that file gettext
> # doesn't believe po/ is a gettext directory and won't generate po/Makefile.
> -EXTRA_AUTORECONF_remove = "--exclude=autopoint"
> +AUTORECONF_REMOVE_ARGS = "--exclude=autopoint"
> +AUTORECONF_REMOVE_ARGS_riscv64 = ""
> +EXTRA_AUTORECONF_remove = "${AUTORECONF_REMOVE_ARGS}"
> do_configure_prepend() {
> ( cd ${S} && po/update-potfiles )
> }
> --
> 2.17.1
>
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/1] db: disable the ARM assembler mutex code
On Thu, Jun 14, 2018 at 12:24 PM, Khem Raj wrote:
> On Thu, Jun 14, 2018 at 12:12 PM Andre McCurdy wrote:
>>
>> On Thu, Jun 14, 2018 at 9:40 AM, Khem Raj wrote:
>> > On 6/14/18 5:10 AM, Herve Jourdain wrote:
>> >> Hi,
>> >>
>> >> I believe I solved that same problem by just adding, in the case of armv8
>> >> (which I believe may be the new architecture you're referring to):
>> >> MUTEX_armv8 = ""
>> >> This way, it allows previous versions to work just like they did before,
>> >> without having to disable ARM assembler mutex code for architectures that
>> >> support it correctly - up to armv7ve I believe.
>> >> Of course, we might need to also have a good definition for armv8, which
>> >> is
>> >> the object of another thread.
>> >
>> > right thats a better approach.
>>
>> SWP is not guaranteed to work on SMP systems... and even if it does,
>> performance is likely to be worse than the pthreads version (which can
>> take advantage of the newer instructions).
>>
>>
>> https://community.arm.com/processors/b/blog/posts/locks-swps-and-two-smoking-barriers
>>
>> In general, use of hand optimised assembler mutex implementations in
>> user space isn't something to be encouraged - use pthreads (or maybe a
>> gcc intrinsic) instead.
>>
>
> question is about disabling it on old arm machines, do we have data where
> we know that other sync methods without swp works better on armv5 and lower ?
On armv5 and below a hand optimised implementation using SWP is likely
to be faster than pthreads. No one is suggesting otherwise.
On SMP (highly likely nowadays for armv7 and above), SWP simply might
not work (aside from the fact that if it does work, it's likely to be
slower than pthreads). It's not really a question of performance
there, so the proposal to only disable SWP for armv8 doesn't seem like
a safe solution.
Using pthreads unconditionally is safe and easy. Unless you can prove
that hand optimised SWP is really a big win for armv5 (is anyone
really running a performance critical database on an armv5 system?)
why not keep the recipe simple and use pthreads everywhere?
>> I think the original patch is good.
>>
>> >> Cheers,
>> >> Herve
>> >>
>> >> -Original Message-
>> >> From: openembedded-core-boun...@lists.openembedded.org
>> >> [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of
>> >> Ovidiu Panait
>> >> Sent: jeudi 14 juin 2018 13:55
>> >> To: openembedded-core@lists.openembedded.org
>> >> Subject: [OE-core] [PATCH 1/1] db: disable the ARM assembler mutex code
>> >>
>> >> The swpb in macro MUTEX_SET will cause "undefined instruction" error on
>> >> the
>> >> new arm arches which don't support this assembly instruction any more. If
>> >> use ldrex/strex to replace swpb, the old arm arches don't support them. So
>> >> to avoid this issue, just disable the ARM assembler mutex code, and use
>> >> the
>> >> default pthreads mutex.
>> >>
>> >> Signed-off-by: Li Zhou
>> >> Signed-off-by: Catalin Enache
>> >> Signed-off-by: Ovidiu Panait
>> >> ---
>> >> meta/recipes-support/db/db_5.3.28.bb | 13 +
>> >> 1 file changed, 1 insertion(+), 12 deletions(-)
>> >>
>> >> diff --git a/meta/recipes-support/db/db_5.3.28.bb
>> >> b/meta/recipes-support/db/db_5.3.28.bb
>> >> index 093ee44909..15b4155a29 100644
>> >> --- a/meta/recipes-support/db/db_5.3.28.bb
>> >> +++ b/meta/recipes-support/db/db_5.3.28.bb
>> >> @@ -59,18 +59,7 @@ FILES_SOLIBSDEV = "${libdir}/libdb.so
>> >> ${libdir}/libdb_cxx.so"
>> >> # All the --disable-* options replace --enable-smallbuild, which breaks a
>> >> bunch of stuff (eg. postfix) DB5_CONFIG ?= "--enable-o_direct
>> >> --disable-cryptography --disable-queue --disable-replication
>> >> --disable-verify --disable-compat185 --disable-sql"
>> >>
>> >> -EXTRA_OECONF = "${DB5_CONFIG} --enable-shared --enable-cxx
>> >> --with-sysroot"
>> >> -
>> >> -# Override the MUTEX setting here, the POSIX library is -# the default -
>> >> "POSIX/pthreads/library".
>> >> -# Don't ignore the nice SWP instruction on the ARM:
>> >> -# These enable the ARM assembler mutex code, this won't -# work with
>> >> thumb
>> >> compilation...
>> >> -ARM_MUTEX = "--with-mutex=ARM/gcc-assembly"
>> >> -MUTEX = ""
>> >> -MUTEX_arm = "${ARM_MUTEX}"
>> >> -MUTEX_armeb = "${ARM_MUTEX}"
>> >> -EXTRA_OECONF += "${MUTEX} STRIP=true"
>> >> +EXTRA_OECONF = "${DB5_CONFIG} --enable-shared --enable-cxx --with-sysroot
>> >> STRIP=true"
>> >> EXTRA_OEMAKE += "LIBTOOL='./${HOST_SYS}-libtool'"
>> >>
>> >> EXTRA_AUTORECONF += "--exclude=autoheader -I ${S}/dist/aclocal
>> >> -I${S}/dist/aclocal_java"
>> >> --
>> >> 2.17.1
>> >>
>> >> --
>> >> ___
>> >> 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
Re: [OE-core] [PATCH] gobject-introspection: relocate typelib repository for native builds
Alexander Kanavin writes: > No, I don't think so. You just need to be patient; patch testing and > merging are done by one overloaded person. If after 2-3 weeks it's not > in, resend. OK, no problem. Sascha -- Softwareentwicklung Sascha Silbe, Niederhofenstraße 5/1, 71229 Leonberg https://se-silbe.de/ USt-IdNr.: DE281696641 signature.asc Description: PGP signature -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/4] recipes-extended/psmisc: Don't exclude autopoint for RISCV
Signed-off-by: Alistair Francis
---
meta/recipes-extended/psmisc/psmisc.inc | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/meta/recipes-extended/psmisc/psmisc.inc
b/meta/recipes-extended/psmisc/psmisc.inc
index 82ef947709..73b4c56f69 100644
--- a/meta/recipes-extended/psmisc/psmisc.inc
+++ b/meta/recipes-extended/psmisc/psmisc.inc
@@ -19,7 +19,9 @@ inherit autotools gettext
# Upstream has a custom autogen.sh which invokes po/update-potfiles as they
# don't ship a po/POTFILES.in (which is silly). Without that file gettext
# doesn't believe po/ is a gettext directory and won't generate po/Makefile.
-EXTRA_AUTORECONF_remove = "--exclude=autopoint"
+AUTORECONF_REMOVE_ARGS = "--exclude=autopoint"
+AUTORECONF_REMOVE_ARGS_riscv64 = ""
+EXTRA_AUTORECONF_remove = "${AUTORECONF_REMOVE_ARGS}"
do_configure_prepend() {
( cd ${S} && po/update-potfiles )
}
--
2.17.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 4/4] recipes-kernel/linux: Add RISC-V support
Signed-off-by: Alistair Francis
---
meta/recipes-kernel/linux/linux-yocto.inc | 4
meta/recipes-kernel/linux/linux-yocto_4.15.bb | 5 -
2 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/meta/recipes-kernel/linux/linux-yocto.inc
b/meta/recipes-kernel/linux/linux-yocto.inc
index 95ec2a2b41..70a13cdd1e 100644
--- a/meta/recipes-kernel/linux/linux-yocto.inc
+++ b/meta/recipes-kernel/linux/linux-yocto.inc
@@ -26,6 +26,10 @@ DEPENDS_append_nios2 = " libgcc"
KERNEL_CC_append_nios2 = " ${TOOLCHAIN_OPTIONS}"
KERNEL_LD_append_nios2 = " ${TOOLCHAIN_OPTIONS}"
+DEPENDS_append_riscv64 = " libgcc"
+KERNEL_CC_append_riscv64 = " ${TOOLCHAIN_OPTIONS} ${SECURITY_NOPIE_CFLAGS}"
+KERNEL_LD_append_riscv64 = " -no-pie"
+
KERNEL_FEATURES_append_qemuall=" features/debug/printk.scc"
# A KMACHINE is the mapping of a yocto $MACHINE to what is built
diff --git a/meta/recipes-kernel/linux/linux-yocto_4.15.bb
b/meta/recipes-kernel/linux/linux-yocto_4.15.bb
index 693670c613..4ea368a011 100644
--- a/meta/recipes-kernel/linux/linux-yocto_4.15.bb
+++ b/meta/recipes-kernel/linux/linux-yocto_4.15.bb
@@ -36,7 +36,10 @@ KCONF_BSP_AUDIT_LEVEL = "2"
KERNEL_DEVICETREE_qemuarm = "versatile-pb.dtb"
-COMPATIBLE_MACHINE =
"qemuarm|qemuarm64|qemux86|qemuppc|qemumips|qemumips64|qemux86-64"
+KBUILD_DEFCONFIG_qemuriscv64 = "defconfig"
+KCONFIG_MODE_qemuriscv64 = "--alldefconfig"
+
+COMPATIBLE_MACHINE =
"qemuarm|qemuarm64|qemux86|qemuppc|qemumips|qemumips64|qemux86-64|qemurisc532|qemuriscv64"
# Functionality flags
KERNEL_EXTRA_FEATURES ?= "features/netfilter/netfilter.scc"
--
2.17.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 3/4] recipes-support/nspr: Add RISC-V support
Signed-off-by: Alistair Francis
---
.../0003-Add-riscv-architecture-support.patch | 103 ++
meta/recipes-support/nspr/nspr_4.19.bb| 1 +
2 files changed, 104 insertions(+)
create mode 100644
meta/recipes-support/nspr/nspr/0003-Add-riscv-architecture-support.patch
diff --git
a/meta/recipes-support/nspr/nspr/0003-Add-riscv-architecture-support.patch
b/meta/recipes-support/nspr/nspr/0003-Add-riscv-architecture-support.patch
new file mode 100644
index 00..14911440bd
--- /dev/null
+++ b/meta/recipes-support/nspr/nspr/0003-Add-riscv-architecture-support.patch
@@ -0,0 +1,103 @@
+From ff3d77742bd3b0272c48ff7472a45e9c537709f2 Mon Sep 17 00:00:00 2001
+From: Khem Raj
+Date: Wed, 4 Oct 2017 11:55:10 -0700
+Subject: [PATCH] Add riscv architecture support
+
+Signed-off-by: Khem Raj
+---
+ pr/include/md/_linux.cfg | 46 ++
+ pr/include/md/_linux.h | 14 ++
+ 2 files changed, 60 insertions(+)
+
+diff --git a/pr/include/md/_linux.cfg b/pr/include/md/_linux.cfg
+index 31296a8..d0dde57 100644
+--- a/pr/include/md/_linux.cfg
b/pr/include/md/_linux.cfg
+@@ -360,6 +360,52 @@
+ #define PR_BYTES_PER_WORD_LOG2 2
+ #define PR_BYTES_PER_DWORD_LOG2 3
+
++#elif defined(__riscv) && __riscv_xlen == 64
++
++#undefIS_BIG_ENDIAN
++#define IS_LITTLE_ENDIAN 1
++#define IS_64
++
++#define PR_BYTES_PER_BYTE 1
++#define PR_BYTES_PER_SHORT 2
++#define PR_BYTES_PER_INT4
++#define PR_BYTES_PER_INT64 8
++#define PR_BYTES_PER_LONG 8
++#define PR_BYTES_PER_FLOAT 4
++#define PR_BYTES_PER_DOUBLE 8
++#define PR_BYTES_PER_WORD 8
++#define PR_BYTES_PER_DWORD 8
++
++#define PR_BITS_PER_BYTE8
++#define PR_BITS_PER_SHORT 16
++#define PR_BITS_PER_INT 32
++#define PR_BITS_PER_INT64 64
++#define PR_BITS_PER_LONG64
++#define PR_BITS_PER_FLOAT 32
++#define PR_BITS_PER_DOUBLE 64
++#define PR_BITS_PER_WORD64
++
++#define PR_BITS_PER_BYTE_LOG2 3
++#define PR_BITS_PER_SHORT_LOG2 4
++#define PR_BITS_PER_INT_LOG25
++#define PR_BITS_PER_INT64_LOG2 6
++#define PR_BITS_PER_LONG_LOG2 6
++#define PR_BITS_PER_FLOAT_LOG2 5
++#define PR_BITS_PER_DOUBLE_LOG2 6
++#define PR_BITS_PER_WORD_LOG2 6
++
++#define PR_ALIGN_OF_SHORT 2
++#define PR_ALIGN_OF_INT 4
++#define PR_ALIGN_OF_INT64 8
++#define PR_ALIGN_OF_LONG8
++#define PR_ALIGN_OF_FLOAT 4
++#define PR_ALIGN_OF_DOUBLE 8
++#define PR_ALIGN_OF_POINTER 8
++#define PR_ALIGN_OF_WORD8
++
++#define PR_BYTES_PER_WORD_LOG2 3
++#define PR_BYTES_PER_DWORD_LOG2 3
++
+ #elif defined(__sparc__) && defined (__arch64__)
+
+ #undefIS_LITTLE_ENDIAN
+diff --git a/pr/include/md/_linux.h b/pr/include/md/_linux.h
+index 551918f..3a3cc2e 100644
+--- a/pr/include/md/_linux.h
b/pr/include/md/_linux.h
+@@ -31,6 +31,8 @@
+ #define _PR_SI_ARCHITECTURE "x86-64"
+ #elif defined(__mc68000__)
+ #define _PR_SI_ARCHITECTURE "m68k"
++#elif defined(__riscv) && __riscv_xlen == 64
++#define _PR_SI_ARCHITECTURE "rv64"
+ #elif defined(__sparc__) && defined(__arch64__)
+ #define _PR_SI_ARCHITECTURE "sparc64"
+ #elif defined(__sparc__)
+@@ -151,6 +153,18 @@ extern PRInt32 _PR_x86_64_AtomicSet(PRInt32 *val, PRInt32
newval);
+ #endif
+ #endif
+
++#if defined(__riscv)
++#if defined(__GNUC__)
++/* Use GCC built-in functions */
++#define _PR_HAVE_ATOMIC_OPS
++#define _MD_INIT_ATOMIC()
++#define _MD_ATOMIC_INCREMENT(ptr) __sync_add_and_fetch(ptr, 1)
++#define _MD_ATOMIC_DECREMENT(ptr) __sync_sub_and_fetch(ptr, 1)
++#define _MD_ATOMIC_ADD(ptr, i) __sync_add_and_fetch(ptr, i)
++#define _MD_ATOMIC_SET(ptr, nv) __sync_lock_test_and_set(ptr, nv)
++#endif
++#endif
++
+ #if defined(__powerpc__) && !defined(__powerpc64__)
+ #define _PR_HAVE_ATOMIC_OPS
+ #define _MD_INIT_ATOMIC()
+--
+2.14.2
+
diff --git a/meta/recipes-support/nspr/nspr_4.19.bb
b/meta/recipes-support/nspr/nspr_4.19.bb
index de2c87131f..5c37509b1b 100644
--- a/meta/recipes-support/nspr/nspr_4.19.bb
+++ b/meta/recipes-support/nspr/nspr_4.19.bb
@@ -11,6 +11,7 @@ SRC_URI =
"http://ftp.mozilla.org/pub/nspr/releases/v${PV}/src/nspr-${PV}.tar.gz
file://remove-srcdir-from-configure-in.patch \
file://0002-Add-nios2-support.patch \
file://0001-md-Fix-build-with-musl.patch \
+ file://0003-Add-riscv-architecture-support.patch \
file://nspr.pc.in \
"
--
2.17.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/4] recipes-devtools/qemu: Add RISC-V support
Signed-off-by: Alistair Francis
---
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 faaea781cd..d1543b81f9 100644
--- a/meta/recipes-devtools/qemu/qemu.inc
+++ b/meta/recipes-devtools/qemu/qemu.inc
@@ -9,7 +9,7 @@ inherit autotools pkgconfig bluetooth
BBCLASSEXTEND = "native nativesdk"
# QEMU_TARGETS is overridable variable
-QEMU_TARGETS ?= "arm aarch64 i386 mips mipsel mips64 mips64el ppc sh4 x86_64"
+QEMU_TARGETS ?= "arm aarch64 i386 mips mipsel mips64 mips64el ppc sh4 x86_64
riscv32 riscv64"
EXTRA_OECONF = " \
--prefix=${prefix} \
--
2.17.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/1] db: disable the ARM assembler mutex code
On Thu, Jun 14, 2018 at 12:12 PM Andre McCurdy wrote:
>
> On Thu, Jun 14, 2018 at 9:40 AM, Khem Raj wrote:
> > On 6/14/18 5:10 AM, Herve Jourdain wrote:
> >> Hi,
> >>
> >> I believe I solved that same problem by just adding, in the case of armv8
> >> (which I believe may be the new architecture you're referring to):
> >> MUTEX_armv8 = ""
> >> This way, it allows previous versions to work just like they did before,
> >> without having to disable ARM assembler mutex code for architectures that
> >> support it correctly - up to armv7ve I believe.
> >> Of course, we might need to also have a good definition for armv8, which is
> >> the object of another thread.
> >
> > right thats a better approach.
>
> SWP is not guaranteed to work on SMP systems... and even if it does,
> performance is likely to be worse than the pthreads version (which can
> take advantage of the newer instructions).
>
>
> https://community.arm.com/processors/b/blog/posts/locks-swps-and-two-smoking-barriers
>
> In general, use of hand optimised assembler mutex implementations in
> user space isn't something to be encouraged - use pthreads (or maybe a
> gcc intrinsic) instead.
>
question is about disabling it on old arm machines, do we have data where
we know that other sync methods without swp works better on armv5 and lower ? Do
we have gcc intrinsics for those versions of arm ?
if we do then I think I would agree
> I think the original patch is good.
>
> >> Cheers,
> >> Herve
> >>
> >> -Original Message-
> >> From: openembedded-core-boun...@lists.openembedded.org
> >> [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of
> >> Ovidiu Panait
> >> Sent: jeudi 14 juin 2018 13:55
> >> To: openembedded-core@lists.openembedded.org
> >> Subject: [OE-core] [PATCH 1/1] db: disable the ARM assembler mutex code
> >>
> >> The swpb in macro MUTEX_SET will cause "undefined instruction" error on the
> >> new arm arches which don't support this assembly instruction any more. If
> >> use ldrex/strex to replace swpb, the old arm arches don't support them. So
> >> to avoid this issue, just disable the ARM assembler mutex code, and use the
> >> default pthreads mutex.
> >>
> >> Signed-off-by: Li Zhou
> >> Signed-off-by: Catalin Enache
> >> Signed-off-by: Ovidiu Panait
> >> ---
> >> meta/recipes-support/db/db_5.3.28.bb | 13 +
> >> 1 file changed, 1 insertion(+), 12 deletions(-)
> >>
> >> diff --git a/meta/recipes-support/db/db_5.3.28.bb
> >> b/meta/recipes-support/db/db_5.3.28.bb
> >> index 093ee44909..15b4155a29 100644
> >> --- a/meta/recipes-support/db/db_5.3.28.bb
> >> +++ b/meta/recipes-support/db/db_5.3.28.bb
> >> @@ -59,18 +59,7 @@ FILES_SOLIBSDEV = "${libdir}/libdb.so
> >> ${libdir}/libdb_cxx.so"
> >> # All the --disable-* options replace --enable-smallbuild, which breaks a
> >> bunch of stuff (eg. postfix) DB5_CONFIG ?= "--enable-o_direct
> >> --disable-cryptography --disable-queue --disable-replication
> >> --disable-verify --disable-compat185 --disable-sql"
> >>
> >> -EXTRA_OECONF = "${DB5_CONFIG} --enable-shared --enable-cxx --with-sysroot"
> >> -
> >> -# Override the MUTEX setting here, the POSIX library is -# the default -
> >> "POSIX/pthreads/library".
> >> -# Don't ignore the nice SWP instruction on the ARM:
> >> -# These enable the ARM assembler mutex code, this won't -# work with thumb
> >> compilation...
> >> -ARM_MUTEX = "--with-mutex=ARM/gcc-assembly"
> >> -MUTEX = ""
> >> -MUTEX_arm = "${ARM_MUTEX}"
> >> -MUTEX_armeb = "${ARM_MUTEX}"
> >> -EXTRA_OECONF += "${MUTEX} STRIP=true"
> >> +EXTRA_OECONF = "${DB5_CONFIG} --enable-shared --enable-cxx --with-sysroot
> >> STRIP=true"
> >> EXTRA_OEMAKE += "LIBTOOL='./${HOST_SYS}-libtool'"
> >>
> >> EXTRA_AUTORECONF += "--exclude=autoheader -I ${S}/dist/aclocal
> >> -I${S}/dist/aclocal_java"
> >> --
> >> 2.17.1
> >>
> >> --
> >> ___
> >> 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
> >
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] ltp: set -fomit-frame-pointer explicitly
On Thu, Jun 14, 2018 at 9:38 AM, Khem Raj wrote:
> On 6/14/18 2:35 AM, mingli...@windriver.com wrote:
>> From: Mingli Yu
>>
>> When build ltp with -fno-omit-frame-pointer,
>> it will trigger below error:
>> | cve-2015-3290.c: In function 'child_thread':
>> | cve-2015-3290.c:416:1: error: bp cannot be used in asm here
>>
>> And there is also some comment as below in the source
>> file ltp/20180515-r0/git/testcases/cve/cve-2015-3290.c
>> * Build with -O2. Don't use -fno-omit-frame-pointer.
>>
>> So explicitly set -fomit-frame-pointer for compiler
>> to fix the above build error.
>>
>> Signed-off-by: Mingli Yu
>> ---
>> meta/recipes-extended/ltp/ltp_20180515.bb | 4
>> 1 file changed, 4 insertions(+)
>>
>> diff --git a/meta/recipes-extended/ltp/ltp_20180515.bb
>> b/meta/recipes-extended/ltp/ltp_20180515.bb
>> index b07c1b9..5ec25ed 100644
>> --- a/meta/recipes-extended/ltp/ltp_20180515.bb
>> +++ b/meta/recipes-extended/ltp/ltp_20180515.bb
>> @@ -19,6 +19,10 @@ LIC_FILES_CHKSUM = "\
>> DEPENDS = "attr libaio libcap acl openssl zip-native"
>> DEPENDS_append_libc-musl = " fts "
>> EXTRA_OEMAKE_append_libc-musl = " LIBC=musl "
>> +
>> +# -fomit-frame-pointer to handle cases where optimisation is set to -O0 or
>> frame
>> +# pointers have been enabled by -fno-omit-frame-pointer earlier in CFLAGS,
>> etc.
>> +CFLAGS_append = " ${@bb.utils.contains('SELECTED_OPTIMIZATION',
>> '-fno-omit-frame-pointer', '-fomit-frame-pointer', '', d)}"
This doesn't cover all cases - there may be times when the compiler
chooses to enable frame pointers without being called with
-fno-omit-frame-pointer.
You could make the append conditional on x86 though (based on the
error message, it's the x86 frame pointer register which is being used
by inline assembler).
> may be just append it unconditionally, what do we lose ?
> CFLAGS += "-fomit-frame-pointer"
>
>> CFLAGS_append_powerpc64 = " -D__SANE_USERSPACE_TYPES__"
>> CFLAGS_append_mipsarchn64 = " -D__SANE_USERSPACE_TYPES__"
>> SRCREV = "96cbf48313afa65ef4d693d3441cbfd60a8d9b27"
>>
>
>
>
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/1] db: disable the ARM assembler mutex code
On Thu, Jun 14, 2018 at 9:40 AM, Khem Raj wrote:
> On 6/14/18 5:10 AM, Herve Jourdain wrote:
>> Hi,
>>
>> I believe I solved that same problem by just adding, in the case of armv8
>> (which I believe may be the new architecture you're referring to):
>> MUTEX_armv8 = ""
>> This way, it allows previous versions to work just like they did before,
>> without having to disable ARM assembler mutex code for architectures that
>> support it correctly - up to armv7ve I believe.
>> Of course, we might need to also have a good definition for armv8, which is
>> the object of another thread.
>
> right thats a better approach.
SWP is not guaranteed to work on SMP systems... and even if it does,
performance is likely to be worse than the pthreads version (which can
take advantage of the newer instructions).
https://community.arm.com/processors/b/blog/posts/locks-swps-and-two-smoking-barriers
In general, use of hand optimised assembler mutex implementations in
user space isn't something to be encouraged - use pthreads (or maybe a
gcc intrinsic) instead.
I think the original patch is good.
>> Cheers,
>> Herve
>>
>> -Original Message-
>> From: openembedded-core-boun...@lists.openembedded.org
>> [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of
>> Ovidiu Panait
>> Sent: jeudi 14 juin 2018 13:55
>> To: openembedded-core@lists.openembedded.org
>> Subject: [OE-core] [PATCH 1/1] db: disable the ARM assembler mutex code
>>
>> The swpb in macro MUTEX_SET will cause "undefined instruction" error on the
>> new arm arches which don't support this assembly instruction any more. If
>> use ldrex/strex to replace swpb, the old arm arches don't support them. So
>> to avoid this issue, just disable the ARM assembler mutex code, and use the
>> default pthreads mutex.
>>
>> Signed-off-by: Li Zhou
>> Signed-off-by: Catalin Enache
>> Signed-off-by: Ovidiu Panait
>> ---
>> meta/recipes-support/db/db_5.3.28.bb | 13 +
>> 1 file changed, 1 insertion(+), 12 deletions(-)
>>
>> diff --git a/meta/recipes-support/db/db_5.3.28.bb
>> b/meta/recipes-support/db/db_5.3.28.bb
>> index 093ee44909..15b4155a29 100644
>> --- a/meta/recipes-support/db/db_5.3.28.bb
>> +++ b/meta/recipes-support/db/db_5.3.28.bb
>> @@ -59,18 +59,7 @@ FILES_SOLIBSDEV = "${libdir}/libdb.so
>> ${libdir}/libdb_cxx.so"
>> # All the --disable-* options replace --enable-smallbuild, which breaks a
>> bunch of stuff (eg. postfix) DB5_CONFIG ?= "--enable-o_direct
>> --disable-cryptography --disable-queue --disable-replication
>> --disable-verify --disable-compat185 --disable-sql"
>>
>> -EXTRA_OECONF = "${DB5_CONFIG} --enable-shared --enable-cxx --with-sysroot"
>> -
>> -# Override the MUTEX setting here, the POSIX library is -# the default -
>> "POSIX/pthreads/library".
>> -# Don't ignore the nice SWP instruction on the ARM:
>> -# These enable the ARM assembler mutex code, this won't -# work with thumb
>> compilation...
>> -ARM_MUTEX = "--with-mutex=ARM/gcc-assembly"
>> -MUTEX = ""
>> -MUTEX_arm = "${ARM_MUTEX}"
>> -MUTEX_armeb = "${ARM_MUTEX}"
>> -EXTRA_OECONF += "${MUTEX} STRIP=true"
>> +EXTRA_OECONF = "${DB5_CONFIG} --enable-shared --enable-cxx --with-sysroot
>> STRIP=true"
>> EXTRA_OEMAKE += "LIBTOOL='./${HOST_SYS}-libtool'"
>>
>> EXTRA_AUTORECONF += "--exclude=autoheader -I ${S}/dist/aclocal
>> -I${S}/dist/aclocal_java"
>> --
>> 2.17.1
>>
>> --
>> ___
>> 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
>
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v2 0/3] postinst fixes for opgk/dpkg
No need to be nervous. The patch will make it in; patches do not get quietly rejected. If it hasn't showed up yet, it's most likely because the patch will be tested on the autobuilder in a separate set from the 'regular patches', or (yes, this happens) it has slipped through the cracks. In that case (I know it's impossible to tell from the outside), just resend again. Also, please do help us out with oe-core patch review and recipe maintenance, particularly updating them to latest versions. Alex 2018-06-14 16:57 GMT+03:00 Stefan Agner : > On 04.06.2018 18:18, Alexander Kanavin wrote: >> On 06/04/2018 07:06 PM, Stefan Agner wrote: >> >>> Anything holding us back merging this changes? >> >> Please read the Yocto project status mail: >> >> " · Patch review/merging was slow over the past week due to >> Ross being on vacation and changes in Richard’s employment/hardware >> situation but at least some of the backlog was resolved over the >> weekend and the hardware issues should be worked around now." >> > > Gentle ping on that again. > > This week it read: > "Due to the milestone, patch merging is slowing to stabilize." > > Also, there have been patches merged which were posted after this > patchset... It is really rather important for us since it is hard to fix > in lower layers... > > So I am getting nervous whether it still makes it? > > -- > Stefan > -- > ___ > 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] gobject-introspection: relocate typelib repository for native builds
No, I don't think so. You just need to be patient; patch testing and merging are done by one overloaded person. If after 2-3 weeks it's not in, resend. Alex 2018-06-14 19:13 GMT+03:00 Sascha Silbe : > Alexander Kanavin writes: > >> 2018-06-08 22:27 GMT+03:00 Sascha Silbe : >>> We have some Python modules that we are extracting some information from >>> and generating documentation for at build time; both times the modules >>> get imported. We don't need GLib to actually work; it only needs to be >>> importable. Fortunately no other typelib is used by the code. >> >> Thanks for explanation. The patch is fine then and can be added to >> oe-core - so that if later g-i needs to be fully supported on the >> native side, this part would be already sorted. For now though it's >> not 'officially' working. > > Fair enough. Thanks for the review! Is there anything else I should do > for the patch to go in? > > Sascha > -- > Softwareentwicklung Sascha Silbe, Niederhofenstraße 5/1, 71229 Leonberg > https://se-silbe.de/ > USt-IdNr.: DE281696641 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH v2] atk: Correct multilib conflict in header.
Signed-off-by: Jeremy Puhlman
---
.../0001-Switch-from-filename-to-basename.patch| 38 ++
meta/recipes-support/atk/atk_2.28.1.bb | 1 +
2 files changed, 39 insertions(+)
create mode 100644
meta/recipes-support/atk/atk/0001-Switch-from-filename-to-basename.patch
diff --git
a/meta/recipes-support/atk/atk/0001-Switch-from-filename-to-basename.patch
b/meta/recipes-support/atk/atk/0001-Switch-from-filename-to-basename.patch
new file mode 100644
index 00..047e81fb61
--- /dev/null
+++ b/meta/recipes-support/atk/atk/0001-Switch-from-filename-to-basename.patch
@@ -0,0 +1,38 @@
+Upstream-Status: Submitted
+
+From 0330251715fee908f2f162565d4fa1df5030d0c0 Mon Sep 17 00:00:00 2001
+From: Jeremy Puhlman
+Date: Thu, 14 Jun 2018 17:21:49 +
+Subject: [PATCH] Switch from filename to basename
+
+When atk-enum-types.h is installed in to a system, the user likely has
+no access to the location where the headers were built, especially if
+the software was built in a sysroot environment. If the headers were
+built for a mulitlib environment, the build pathing may be different.
+Subsequently, if two mulitlib variants of atk are installed together the
+headers conflict for no other reason then they were built in two
+different locations. Switching from filename to basename, still should
+provide sufficient information on the providence of the enums, while not
+conflicting for really no good reason.
+
+Signed-off-by: Jeremy Puhlman
+---
+ atk/atk-enum-types.h.template | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/atk/atk-enum-types.h.template b/atk/atk-enum-types.h.template
+index 7b4cec4..8321c24 100644
+--- a/atk/atk-enum-types.h.template
b/atk/atk-enum-types.h.template
+@@ -14,7 +14,7 @@ G_BEGIN_DECLS
+
+ /*** BEGIN file-production ***/
+
+-/* enumerations from "@filename@" */
++/* enumerations from "@basename@" */
+ /*** END file-production ***/
+
+ /*** BEGIN value-header ***/
+--
+2.14.1.459.g238e487
+
diff --git a/meta/recipes-support/atk/atk_2.28.1.bb
b/meta/recipes-support/atk/atk_2.28.1.bb
index 657c69d576..a051247d8f 100644
--- a/meta/recipes-support/atk/atk_2.28.1.bb
+++ b/meta/recipes-support/atk/atk_2.28.1.bb
@@ -27,6 +27,7 @@ EXTRA_OEMESON_append_class-target = "
${@bb.utils.contains('GTKDOC_ENABLED', 'Tr
SRC_URI_append = " \
file://0001-meson.build-enable-introspection-for-cross-compile.patch \
+ file://0001-Switch-from-filename-to-basename.patch \
"
SRC_URI[archive.md5sum] = "dfb5e7474220afa3f4ca7e45af9f3a11"
SRC_URI[archive.sha256sum] =
"cd3a1ea6ecc268a2497f0cd018e970860de24a6d42086919d6bf6c8e8d53f4fc"
--
2.14.1.459.g238e487
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH v2][sumo] Qemu: CVE-2018-11806 slirp-heap-buffer-overflow
Signed-off-by: Jeremy Puhlman
---
...018-11806-QEMU-slirp-heap-buffer-overflow.patch | 69 ++
meta/recipes-devtools/qemu/qemu_2.11.1.bb | 1 +
2 files changed, 70 insertions(+)
create mode 100644
meta/recipes-devtools/qemu/qemu/0001-CVE-2018-11806-QEMU-slirp-heap-buffer-overflow.patch
diff --git
a/meta/recipes-devtools/qemu/qemu/0001-CVE-2018-11806-QEMU-slirp-heap-buffer-overflow.patch
b/meta/recipes-devtools/qemu/qemu/0001-CVE-2018-11806-QEMU-slirp-heap-buffer-overflow.patch
new file mode 100644
index 00..8622360114
--- /dev/null
+++
b/meta/recipes-devtools/qemu/qemu/0001-CVE-2018-11806-QEMU-slirp-heap-buffer-overflow.patch
@@ -0,0 +1,69 @@
+Upstream-Status: Backport
+
+https://lists.gnu.org/archive/html/qemu-devel/2018-06/msg01012.html
+
+From dc21a9d2951f0a2a7e63633e2b5c68c54e4edc4b Mon Sep 17 00:00:00 2001
+From: Jeremy Puhlman
+Date: Thu, 14 Jun 2018 01:28:49 +
+Subject: [PATCH] CVE-2018-11806 QEMU: slirp: heap buffer overflow
+
+Subject: [Qemu-devel] [PATCH 1/2] slirp: correct size computation while
concatenating mbuf
+Date: Tue, 5 Jun 2018 23:38:35 +0530
+From: Prasad J Pandit
+
+While reassembling incoming fragmented datagrams, 'm_cat' routine
+extends the 'mbuf' buffer, if it has insufficient room. It computes
+a wrong buffer size, which leads to overwriting adjacent heap buffer
+area. Correct this size computation in m_cat.
+
+Reported-by: ZDI Disclosures
+Signed-off-by: Prasad J Pandit
+---
+ slirp/mbuf.c | 8
+ 1 file changed, 4 insertions(+), 4 deletions(-)
+
+Signed-off-by: Jeremy Puhlman
+---
+ slirp/mbuf.c | 8
+ 1 file changed, 4 insertions(+), 4 deletions(-)
+
+diff --git a/slirp/mbuf.c b/slirp/mbuf.c
+index 5ff2455..7fb4501 100644
+--- a/slirp/mbuf.c
b/slirp/mbuf.c
+@@ -138,7 +138,7 @@ m_cat(struct mbuf *m, struct mbuf *n)
+* If there's no room, realloc
+*/
+ if (M_FREEROOM(m) < n->m_len)
+- m_inc(m,m->m_size+MINCSIZE);
++ m_inc(m, m->m_len + n->m_len);
+
+ memcpy(m->m_data+m->m_len, n->m_data, n->m_len);
+ m->m_len += n->m_len;
+@@ -158,12 +158,12 @@ m_inc(struct mbuf *m, int size)
+
+ if (m->m_flags & M_EXT) {
+ datasize = m->m_data - m->m_ext;
+- m->m_ext = g_realloc(m->m_ext, size);
++ m->m_ext = g_realloc(m->m_ext, size + datasize);
+ m->m_data = m->m_ext + datasize;
+ } else {
+ char *dat;
+ datasize = m->m_data - m->m_dat;
+- dat = g_malloc(size);
++ dat = g_malloc(size + datasize);
+ memcpy(dat, m->m_dat, m->m_size);
+
+ m->m_ext = dat;
+@@ -171,7 +171,7 @@ m_inc(struct mbuf *m, int size)
+ m->m_flags |= M_EXT;
+ }
+
+-m->m_size = size;
++m->m_size = size + datasize;
+
+ }
+
+--
+2.13.3
+
diff --git a/meta/recipes-devtools/qemu/qemu_2.11.1.bb
b/meta/recipes-devtools/qemu/qemu_2.11.1.bb
index f4b7d69fca..5dc3934f62 100644
--- a/meta/recipes-devtools/qemu/qemu_2.11.1.bb
+++ b/meta/recipes-devtools/qemu/qemu_2.11.1.bb
@@ -22,6 +22,7 @@ SRC_URI =
"http://wiki.qemu-project.org/download/${BP}.tar.bz2 \
file://linux-user-Fix-webkitgtk-hangs-on-32-bit-x86-target.patch \
file://memfd.patch \
file://0001-arm-translate-a64-treat-DISAS_UPDATE-as-variant-of-D.patch \
+ file://0001-CVE-2018-11806-QEMU-slirp-heap-buffer-overflow.patch \
"
UPSTREAM_CHECK_REGEX = "qemu-(?P\d+\..*)\.tar"
--
2.14.1.459.g238e487
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/1] db: disable the ARM assembler mutex code
On 6/14/18 5:10 AM, Herve Jourdain wrote:
> Hi,
>
> I believe I solved that same problem by just adding, in the case of armv8
> (which I believe may be the new architecture you're referring to):
> MUTEX_armv8 = ""
> This way, it allows previous versions to work just like they did before,
> without having to disable ARM assembler mutex code for architectures that
> support it correctly - up to armv7ve I believe.
> Of course, we might need to also have a good definition for armv8, which is
> the object of another thread.
right thats a better approach.
>
> Cheers,
> Herve
>
> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org
> [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of
> Ovidiu Panait
> Sent: jeudi 14 juin 2018 13:55
> To: openembedded-core@lists.openembedded.org
> Subject: [OE-core] [PATCH 1/1] db: disable the ARM assembler mutex code
>
> The swpb in macro MUTEX_SET will cause "undefined instruction" error on the
> new arm arches which don't support this assembly instruction any more. If
> use ldrex/strex to replace swpb, the old arm arches don't support them. So
> to avoid this issue, just disable the ARM assembler mutex code, and use the
> default pthreads mutex.
>
> Signed-off-by: Li Zhou
> Signed-off-by: Catalin Enache
> Signed-off-by: Ovidiu Panait
> ---
> meta/recipes-support/db/db_5.3.28.bb | 13 +
> 1 file changed, 1 insertion(+), 12 deletions(-)
>
> diff --git a/meta/recipes-support/db/db_5.3.28.bb
> b/meta/recipes-support/db/db_5.3.28.bb
> index 093ee44909..15b4155a29 100644
> --- a/meta/recipes-support/db/db_5.3.28.bb
> +++ b/meta/recipes-support/db/db_5.3.28.bb
> @@ -59,18 +59,7 @@ FILES_SOLIBSDEV = "${libdir}/libdb.so
> ${libdir}/libdb_cxx.so"
> # All the --disable-* options replace --enable-smallbuild, which breaks a
> bunch of stuff (eg. postfix) DB5_CONFIG ?= "--enable-o_direct
> --disable-cryptography --disable-queue --disable-replication
> --disable-verify --disable-compat185 --disable-sql"
>
> -EXTRA_OECONF = "${DB5_CONFIG} --enable-shared --enable-cxx --with-sysroot"
> -
> -# Override the MUTEX setting here, the POSIX library is -# the default -
> "POSIX/pthreads/library".
> -# Don't ignore the nice SWP instruction on the ARM:
> -# These enable the ARM assembler mutex code, this won't -# work with thumb
> compilation...
> -ARM_MUTEX = "--with-mutex=ARM/gcc-assembly"
> -MUTEX = ""
> -MUTEX_arm = "${ARM_MUTEX}"
> -MUTEX_armeb = "${ARM_MUTEX}"
> -EXTRA_OECONF += "${MUTEX} STRIP=true"
> +EXTRA_OECONF = "${DB5_CONFIG} --enable-shared --enable-cxx --with-sysroot
> STRIP=true"
> EXTRA_OEMAKE += "LIBTOOL='./${HOST_SYS}-libtool'"
>
> EXTRA_AUTORECONF += "--exclude=autoheader -I ${S}/dist/aclocal
> -I${S}/dist/aclocal_java"
> --
> 2.17.1
>
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
signature.asc
Description: OpenPGP digital signature
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] ltp: set -fomit-frame-pointer explicitly
On 6/14/18 2:35 AM, mingli...@windriver.com wrote:
> From: Mingli Yu
>
> When build ltp with -fno-omit-frame-pointer,
> it will trigger below error:
> | cve-2015-3290.c: In function 'child_thread':
> | cve-2015-3290.c:416:1: error: bp cannot be used in asm here
>
> And there is also some comment as below in the source
> file ltp/20180515-r0/git/testcases/cve/cve-2015-3290.c
> * Build with -O2. Don't use -fno-omit-frame-pointer.
>
> So explicitly set -fomit-frame-pointer for compiler
> to fix the above build error.
>
> Signed-off-by: Mingli Yu
> ---
> meta/recipes-extended/ltp/ltp_20180515.bb | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/meta/recipes-extended/ltp/ltp_20180515.bb
> b/meta/recipes-extended/ltp/ltp_20180515.bb
> index b07c1b9..5ec25ed 100644
> --- a/meta/recipes-extended/ltp/ltp_20180515.bb
> +++ b/meta/recipes-extended/ltp/ltp_20180515.bb
> @@ -19,6 +19,10 @@ LIC_FILES_CHKSUM = "\
> DEPENDS = "attr libaio libcap acl openssl zip-native"
> DEPENDS_append_libc-musl = " fts "
> EXTRA_OEMAKE_append_libc-musl = " LIBC=musl "
> +
> +# -fomit-frame-pointer to handle cases where optimisation is set to -O0 or
> frame
> +# pointers have been enabled by -fno-omit-frame-pointer earlier in CFLAGS,
> etc.
> +CFLAGS_append = " ${@bb.utils.contains('SELECTED_OPTIMIZATION',
> '-fno-omit-frame-pointer', '-fomit-frame-pointer', '', d)}"
may be just append it unconditionally, what do we lose ?
CFLAGS += "-fomit-frame-pointer"
> CFLAGS_append_powerpc64 = " -D__SANE_USERSPACE_TYPES__"
> CFLAGS_append_mipsarchn64 = " -D__SANE_USERSPACE_TYPES__"
> SRCREV = "96cbf48313afa65ef4d693d3441cbfd60a8d9b27"
>
signature.asc
Description: OpenPGP digital signature
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] tune-ppce500v1: Add a tune file for PowerPC e500v1 cores
Hi Chunrong
On 6/14/18 2:25 AM, chunrong@nxp.com wrote:
> From: Chunrong Guo
>
> Signed-off-by: Chunrong Guo
> ---
> meta/conf/machine/include/tune-ppce500v1.inc | 20
> 1 file changed, 20 insertions(+)
> create mode 100644 meta/conf/machine/include/tune-ppce500v1.inc
>
> diff --git a/meta/conf/machine/include/tune-ppce500v1.inc
> b/meta/conf/machine/include/tune-ppce500v1.inc
> new file mode 100644
> index 000..509c81b
> --- /dev/null
> +++ b/meta/conf/machine/include/tune-ppce500v1.inc
> @@ -0,0 +1,20 @@
> +DEFAULTTUNE ?= "ppce500v1"
> +
> +require conf/machine/include/powerpc/arch-powerpc.inc
> +
> +TUNEVALID[ppce500v1] = "Enable ppce500v1 specific processor optimizations"
> +TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'ppce500v1', '
> -mcpu=8540', '', d)}"
> +
> +TUNEVALID[spe] = "Enable SPE ABI extensions"
> +TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', [ 'ppce500v1', 'spe'
> ], ' -mabi=spe -mspe -mfloat-gprs=double', '', d)}"
> +TARGET_FPU .= "${@bb.utils.contains('TUNE_FEATURES', [ 'ppce500v1' , 'spe'
> ], 'ppc-efd', '', d)}"
> +
> +# spe is defined potentially in two places, so we want to be sure it will
> +# only write spe once to the ABIEXTENSIONS field.
> +SPEABIEXTENSION = "${@bb.utils.filter('TUNE_FEATURES', 'spe', d)}"
> +ABIEXTENSION .= "${SPEABIEXTENSION}"
> +
> +AVAILTUNES += "ppce500v1"
> +TUNE_FEATURES_tune-ppce500v1 = "m32 spe ppce500v1"
> +TUNE_PKGARCH_tune-ppce500v1 = "ppce500v1"
> +PACKAGE_EXTRA_ARCHS_tune-ppce500v1 = "ppce500v1"
>
I must inform that spe backend is moved into obsoleted backends in gcc
and is slated to be gone in gcc9 unless someone shows up to maintain it.
With that in mind, I think we should wait and not add this to oe-core
since this will also become obsolete as we move to new compiler.
signature.asc
Description: OpenPGP digital signature
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] gobject-introspection: relocate typelib repository for native builds
Alexander Kanavin writes: > 2018-06-08 22:27 GMT+03:00 Sascha Silbe : >> We have some Python modules that we are extracting some information from >> and generating documentation for at build time; both times the modules >> get imported. We don't need GLib to actually work; it only needs to be >> importable. Fortunately no other typelib is used by the code. > > Thanks for explanation. The patch is fine then and can be added to > oe-core - so that if later g-i needs to be fully supported on the > native side, this part would be already sorted. For now though it's > not 'officially' working. Fair enough. Thanks for the review! Is there anything else I should do for the patch to go in? Sascha -- Softwareentwicklung Sascha Silbe, Niederhofenstraße 5/1, 71229 Leonberg https://se-silbe.de/ USt-IdNr.: DE281696641 signature.asc Description: PGP signature -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH v2] Qemu: CVE-2018-11806 slirp heap buffer overflow
Signed-off-by: Jeremy Puhlman
---
...018-11806-QEMU-slirp-heap-buffer-overflow.patch | 69 ++
meta/recipes-devtools/qemu/qemu_2.12.0.bb | 1 +
2 files changed, 70 insertions(+)
create mode 100644
meta/recipes-devtools/qemu/qemu/0001-CVE-2018-11806-QEMU-slirp-heap-buffer-overflow.patch
diff --git
a/meta/recipes-devtools/qemu/qemu/0001-CVE-2018-11806-QEMU-slirp-heap-buffer-overflow.patch
b/meta/recipes-devtools/qemu/qemu/0001-CVE-2018-11806-QEMU-slirp-heap-buffer-overflow.patch
new file mode 100644
index 00..8622360114
--- /dev/null
+++
b/meta/recipes-devtools/qemu/qemu/0001-CVE-2018-11806-QEMU-slirp-heap-buffer-overflow.patch
@@ -0,0 +1,69 @@
+Upstream-Status: Backport
+
+https://lists.gnu.org/archive/html/qemu-devel/2018-06/msg01012.html
+
+From dc21a9d2951f0a2a7e63633e2b5c68c54e4edc4b Mon Sep 17 00:00:00 2001
+From: Jeremy Puhlman
+Date: Thu, 14 Jun 2018 01:28:49 +
+Subject: [PATCH] CVE-2018-11806 QEMU: slirp: heap buffer overflow
+
+Subject: [Qemu-devel] [PATCH 1/2] slirp: correct size computation while
concatenating mbuf
+Date: Tue, 5 Jun 2018 23:38:35 +0530
+From: Prasad J Pandit
+
+While reassembling incoming fragmented datagrams, 'm_cat' routine
+extends the 'mbuf' buffer, if it has insufficient room. It computes
+a wrong buffer size, which leads to overwriting adjacent heap buffer
+area. Correct this size computation in m_cat.
+
+Reported-by: ZDI Disclosures
+Signed-off-by: Prasad J Pandit
+---
+ slirp/mbuf.c | 8
+ 1 file changed, 4 insertions(+), 4 deletions(-)
+
+Signed-off-by: Jeremy Puhlman
+---
+ slirp/mbuf.c | 8
+ 1 file changed, 4 insertions(+), 4 deletions(-)
+
+diff --git a/slirp/mbuf.c b/slirp/mbuf.c
+index 5ff2455..7fb4501 100644
+--- a/slirp/mbuf.c
b/slirp/mbuf.c
+@@ -138,7 +138,7 @@ m_cat(struct mbuf *m, struct mbuf *n)
+* If there's no room, realloc
+*/
+ if (M_FREEROOM(m) < n->m_len)
+- m_inc(m,m->m_size+MINCSIZE);
++ m_inc(m, m->m_len + n->m_len);
+
+ memcpy(m->m_data+m->m_len, n->m_data, n->m_len);
+ m->m_len += n->m_len;
+@@ -158,12 +158,12 @@ m_inc(struct mbuf *m, int size)
+
+ if (m->m_flags & M_EXT) {
+ datasize = m->m_data - m->m_ext;
+- m->m_ext = g_realloc(m->m_ext, size);
++ m->m_ext = g_realloc(m->m_ext, size + datasize);
+ m->m_data = m->m_ext + datasize;
+ } else {
+ char *dat;
+ datasize = m->m_data - m->m_dat;
+- dat = g_malloc(size);
++ dat = g_malloc(size + datasize);
+ memcpy(dat, m->m_dat, m->m_size);
+
+ m->m_ext = dat;
+@@ -171,7 +171,7 @@ m_inc(struct mbuf *m, int size)
+ m->m_flags |= M_EXT;
+ }
+
+-m->m_size = size;
++m->m_size = size + datasize;
+
+ }
+
+--
+2.13.3
+
diff --git a/meta/recipes-devtools/qemu/qemu_2.12.0.bb
b/meta/recipes-devtools/qemu/qemu_2.12.0.bb
index 21796df9d7..98db44a8ef 100644
--- a/meta/recipes-devtools/qemu/qemu_2.12.0.bb
+++ b/meta/recipes-devtools/qemu/qemu_2.12.0.bb
@@ -21,6 +21,7 @@ SRC_URI =
"http://wiki.qemu-project.org/download/${BP}.tar.bz2 \
file://0009-apic-fixup-fallthrough-to-PIC.patch \
file://0010-linux-user-Fix-webkitgtk-hangs-on-32-bit-x86-target.patch \
file://0011-Revert-linux-user-fix-mmap-munmap-mprotect-mremap-sh.patch \
+ file://0001-CVE-2018-11806-QEMU-slirp-heap-buffer-overflow.patch \
"
UPSTREAM_CHECK_REGEX = "qemu-(?P\d+\..*)\.tar"
--
2.14.1.459.g238e487
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v2 0/3] postinst fixes for opgk/dpkg
On 04.06.2018 18:18, Alexander Kanavin wrote: > On 06/04/2018 07:06 PM, Stefan Agner wrote: > >> Anything holding us back merging this changes? > > Please read the Yocto project status mail: > > " · Patch review/merging was slow over the past week due to > Ross being on vacation and changes in Richard’s employment/hardware > situation but at least some of the backlog was resolved over the > weekend and the hardware issues should be worked around now." > Gentle ping on that again. This week it read: "Due to the milestone, patch merging is slowing to stabilize." Also, there have been patches merged which were posted after this patchset... It is really rather important for us since it is hard to fix in lower layers... So I am getting nervous whether it still makes it? -- Stefan -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v3] ltp: fix cve-2017-5669 test case
On 13 June 2018 at 23:10, Saul Wold wrote: > Can this be backported to both Rocko and Sumo? This can be backported to both Rocko and not sure about Sumo (I did not work on Sumo branch). > > Or is this a case to update LTP in those older releases? Latest LTP + this fix patch (upstream accepted). - Naresh -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v4 01/12] gstreamer: enable ptest support
Picked, thanks. Tested it and it passed too! :) Ross On 14 June 2018 at 02:06, Anuj Mittal wrote: > Ping. > > On 05/25/2018 02:20 PM, Anuj Mittal wrote: >> Make sure that the tests are packaged and can be executed >> when ptest is enabled. Also, remove build host specific references >> from Makefile. >> >> Signed-off-by: Anuj Mittal >> --- >> >> v4: >> Tweak AM_TESTS_ENVIRONMENT to remove hardcoded paths. >> >> --- >> .../files/add-a-target-to-compile-tests.patch | 69 +++ >> .../gstreamer/files/run-ptest | 3 + >> .../gstreamer/gstreamer1.0_1.14.0.bb | 26 ++- >> 3 files changed, 96 insertions(+), 2 deletions(-) >> create mode 100644 >> meta/recipes-multimedia/gstreamer/files/add-a-target-to-compile-tests.patch >> create mode 100644 meta/recipes-multimedia/gstreamer/files/run-ptest >> >> diff --git >> a/meta/recipes-multimedia/gstreamer/files/add-a-target-to-compile-tests.patch >> >> b/meta/recipes-multimedia/gstreamer/files/add-a-target-to-compile-tests.patch >> new file mode 100644 >> index 00..d02d869410 >> --- /dev/null >> +++ >> b/meta/recipes-multimedia/gstreamer/files/add-a-target-to-compile-tests.patch >> @@ -0,0 +1,69 @@ >> +From d61414bc17cf2df019510c2908048c4cabf5cf09 Mon Sep 17 00:00:00 2001 >> +From: Anuj Mittal >> +Date: Tue, 27 Feb 2018 09:27:01 +0800 >> +Subject: [PATCH] add targets for test installation >> + >> +Targets to make sure tests can be installed and then run on >> +the target. >> + >> +Upstream-Status: Inappropriate [specific to oe setup] >> + >> +Signed-off-by: Anuj Mittal >> + >> +--- >> + tests/check/Makefile.am | 27 --- >> + 1 file changed, 20 insertions(+), 7 deletions(-) >> + >> +diff --git a/tests/check/Makefile.am b/tests/check/Makefile.am >> +index 13b916d..a66786d 100644 >> +--- a/tests/check/Makefile.am >> b/tests/check/Makefile.am >> +@@ -8,11 +8,7 @@ REGISTRY_ENVIRONMENT = \ >> + GST_REGISTRY=$(CHECK_REGISTRY) >> + >> + AM_TESTS_ENVIRONMENT += \ >> +-GST_STATE_IGNORE_ELEMENTS="$(STATE_IGNORE_ELEMENTS)"\ >> +-$(REGISTRY_ENVIRONMENT) \ >> +- >> GST_PLUGIN_SCANNER_1_0=$(top_builddir)/libs/gst/helpers/gst-plugin-scanner \ >> +-GST_PLUGIN_SYSTEM_PATH_1_0= \ >> +-GST_PLUGIN_PATH_1_0=$(top_builddir)/plugins >> ++GST_STATE_IGNORE_ELEMENTS="$(STATE_IGNORE_ELEMENTS)" >> + >> + plugindir = $(libdir)/gstreamer-@GST_API_VERSION@ >> + >> +@@ -178,6 +174,23 @@ noinst_PROGRAMS = >> + >> + TESTS = $(check_PROGRAMS) >> + >> ++install-ptest: $(TESTS) >> ++@$(INSTALL) -d $(DESTDIR) >> ++@for dir in `find -maxdepth 1 -type d`; do \ >> ++if [ -x $$dir/.libs ]; then \ >> ++$(INSTALL) -d $(DESTDIR)/$$dir; \ >> ++$(INSTALL_PROGRAM) $$dir/.libs/* $(DESTDIR)/$$dir/; \ >> ++fi \ >> ++done >> ++ >> ++runtests: >> ++@for b in $(TESTS); do \ >> ++if [ -x $$b ]; then \ >> ++$(AM_TESTS_ENVIRONMENT) $(SHELL) test-driver >> --test-name "$$b" \ >> ++--log-file $$b.log --trs-file $$b.trs $$b; \ >> ++fi \ >> ++done >> ++ >> + noinst_HEADERS = \ >> + gst/capslist.h \ >> + gst/struct_arm.h \ >> +@@ -221,9 +234,9 @@ gst_gstprintf_LDADD = \ >> + $(LDADD) >> + >> + elements_fdsrc_CFLAGS=$(GST_OBJ_CFLAGS) $(AM_CFLAGS) \ >> +--DTESTFILE=\"$(top_srcdir)/configure.ac\" >> ++-DTESTFILE=\"Makefile\" >> + elements_filesrc_CFLAGS=$(GST_OBJ_CFLAGS) $(AM_CFLAGS) \ >> +--DTESTFILE=\"$(top_srcdir)/configure.ac\" >> ++-DTESTFILE=\"Makefile\" >> + >> + libs_controller_LDADD = \ >> + >> $(top_builddir)/libs/gst/controller/libgstcontroller-@GST_API_VERSION@.la \ >> diff --git a/meta/recipes-multimedia/gstreamer/files/run-ptest >> b/meta/recipes-multimedia/gstreamer/files/run-ptest >> new file mode 100644 >> index 00..473d0b67a7 >> --- /dev/null >> +++ b/meta/recipes-multimedia/gstreamer/files/run-ptest >> @@ -0,0 +1,3 @@ >> +#!/bin/sh >> + >> +make -k runtests >> diff --git a/meta/recipes-multimedia/gstreamer/gstreamer1.0_1.14.0.bb >> b/meta/recipes-multimedia/gstreamer/gstreamer1.0_1.14.0.bb >> index b4398c8111..e842f30c5a 100644 >> --- a/meta/recipes-multimedia/gstreamer/gstreamer1.0_1.14.0.bb >> +++ b/meta/recipes-multimedia/gstreamer/gstreamer1.0_1.14.0.bb >> @@ -8,7 +8,7 @@ LICENSE = "LGPLv2+" >> >> DEPENDS = "glib-2.0 glib-2.0-native libcap libxml2 bison-native flex-native" >> >> -inherit autotools pkgconfig gettext upstream-version-is-even >> gobject-introspection gtk-doc >> +inherit autotools pkgconfig gettext upstream-version-is-even >> gobject-introspection gtk-doc ptest >> >> # This way common/m4/introspection.m4 will come first >> # (it has a custom INTROSPECTION_INIT macro, and so must be used instead of >> our common introspection.m4 file) >> @@ -24,11 +24,14 @@ SRC_URI = " \ >> file://000
Re: [OE-core] [PATCH] Qemu: CVE-2018-11806 slirp heap buffer overflow
This patch needs an Upstream-Status: Backport and CVE tag in the
header (at the top of the patch from upstream).
Ross
On 14 June 2018 at 04:35, Jeremy Puhlman wrote:
> ---
> ...018-11806-QEMU-slirp-heap-buffer-overflow.patch | 65
> ++
> meta/recipes-devtools/qemu/qemu_2.12.0.bb | 1 +
> 2 files changed, 66 insertions(+)
> create mode 100644
> meta/recipes-devtools/qemu/qemu/0001-CVE-2018-11806-QEMU-slirp-heap-buffer-overflow.patch
>
> diff --git
> a/meta/recipes-devtools/qemu/qemu/0001-CVE-2018-11806-QEMU-slirp-heap-buffer-overflow.patch
>
> b/meta/recipes-devtools/qemu/qemu/0001-CVE-2018-11806-QEMU-slirp-heap-buffer-overflow.patch
> new file mode 100644
> index 00..002a1332bf
> --- /dev/null
> +++
> b/meta/recipes-devtools/qemu/qemu/0001-CVE-2018-11806-QEMU-slirp-heap-buffer-overflow.patch
> @@ -0,0 +1,65 @@
> +From dc21a9d2951f0a2a7e63633e2b5c68c54e4edc4b Mon Sep 17 00:00:00 2001
> +From: Jeremy Puhlman
> +Date: Thu, 14 Jun 2018 01:28:49 +
> +Subject: [PATCH] CVE-2018-11806 QEMU: slirp: heap buffer overflow
> +
> +Subject: [Qemu-devel] [PATCH 1/2] slirp: correct size computation while
> concatenating mbuf
> +Date: Tue, 5 Jun 2018 23:38:35 +0530
> +From: Prasad J Pandit
> +
> +While reassembling incoming fragmented datagrams, 'm_cat' routine
> +extends the 'mbuf' buffer, if it has insufficient room. It computes
> +a wrong buffer size, which leads to overwriting adjacent heap buffer
> +area. Correct this size computation in m_cat.
> +
> +Reported-by: ZDI Disclosures
> +Signed-off-by: Prasad J Pandit
> +---
> + slirp/mbuf.c | 8
> + 1 file changed, 4 insertions(+), 4 deletions(-)
> +
> +Signed-off-by: Jeremy Puhlman
> +---
> + slirp/mbuf.c | 8
> + 1 file changed, 4 insertions(+), 4 deletions(-)
> +
> +diff --git a/slirp/mbuf.c b/slirp/mbuf.c
> +index 5ff2455..7fb4501 100644
> +--- a/slirp/mbuf.c
> b/slirp/mbuf.c
> +@@ -138,7 +138,7 @@ m_cat(struct mbuf *m, struct mbuf *n)
> +* If there's no room, realloc
> +*/
> + if (M_FREEROOM(m) < n->m_len)
> +- m_inc(m,m->m_size+MINCSIZE);
> ++ m_inc(m, m->m_len + n->m_len);
> +
> + memcpy(m->m_data+m->m_len, n->m_data, n->m_len);
> + m->m_len += n->m_len;
> +@@ -158,12 +158,12 @@ m_inc(struct mbuf *m, int size)
> +
> + if (m->m_flags & M_EXT) {
> + datasize = m->m_data - m->m_ext;
> +- m->m_ext = g_realloc(m->m_ext, size);
> ++ m->m_ext = g_realloc(m->m_ext, size + datasize);
> + m->m_data = m->m_ext + datasize;
> + } else {
> + char *dat;
> + datasize = m->m_data - m->m_dat;
> +- dat = g_malloc(size);
> ++ dat = g_malloc(size + datasize);
> + memcpy(dat, m->m_dat, m->m_size);
> +
> + m->m_ext = dat;
> +@@ -171,7 +171,7 @@ m_inc(struct mbuf *m, int size)
> + m->m_flags |= M_EXT;
> + }
> +
> +-m->m_size = size;
> ++m->m_size = size + datasize;
> +
> + }
> +
> +--
> +2.13.3
> +
> diff --git a/meta/recipes-devtools/qemu/qemu_2.12.0.bb
> b/meta/recipes-devtools/qemu/qemu_2.12.0.bb
> index 21796df9d7..98db44a8ef 100644
> --- a/meta/recipes-devtools/qemu/qemu_2.12.0.bb
> +++ b/meta/recipes-devtools/qemu/qemu_2.12.0.bb
> @@ -21,6 +21,7 @@ SRC_URI =
> "http://wiki.qemu-project.org/download/${BP}.tar.bz2 \
> file://0009-apic-fixup-fallthrough-to-PIC.patch \
>
> file://0010-linux-user-Fix-webkitgtk-hangs-on-32-bit-x86-target.patch \
>
> file://0011-Revert-linux-user-fix-mmap-munmap-mprotect-mremap-sh.patch \
> + file://0001-CVE-2018-11806-QEMU-slirp-heap-buffer-overflow.patch \
> "
> UPSTREAM_CHECK_REGEX = "qemu-(?P\d+\..*)\.tar"
>
> --
> 2.14.1.459.g238e487
>
> --
> ___
> 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] meson: class improvements
Ensure that the PACKAGECONFIG arguments are always in EXTRA_OEMESON, and log the
arguments that are being passed in do_configure.
Signed-off-by: Ross Burton
---
meta/classes/meson.bbclass | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/meta/classes/meson.bbclass b/meta/classes/meson.bbclass
index 2c7ce806584..78c5bf3c333 100644
--- a/meta/classes/meson.bbclass
+++ b/meta/classes/meson.bbclass
@@ -35,7 +35,7 @@ MESON_LINK_ARGS = "${MESON_TOOLCHAIN_ARGS} ${LDFLAGS}"
MESON_HOST_ENDIAN = "bogus-endian"
MESON_TARGET_ENDIAN = "bogus-endian"
-EXTRA_OEMESON += "${PACKAGECONFIG_CONFARGS}"
+EXTRA_OEMESON_append = " ${PACKAGECONFIG_CONFARGS}"
MESON_CROSS_FILE = ""
MESON_CROSS_FILE_class-target = "--cross-file ${WORKDIR}/meson.cross"
@@ -85,6 +85,7 @@ EOF
CONFIGURE_FILES = "meson.build"
meson_do_configure() {
+bbnote Executing meson ${EXTRA_OEMESON}...
if ! meson ${MESONOPTS} "${MESON_SOURCEPATH}" "${B}" ${MESON_CROSS_FILE}
${EXTRA_OEMESON}; then
bbfatal_log meson failed
fi
--
2.11.0
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/1] db: disable the ARM assembler mutex code
Hi,
I believe I solved that same problem by just adding, in the case of armv8
(which I believe may be the new architecture you're referring to):
MUTEX_armv8 = ""
This way, it allows previous versions to work just like they did before,
without having to disable ARM assembler mutex code for architectures that
support it correctly - up to armv7ve I believe.
Of course, we might need to also have a good definition for armv8, which is
the object of another thread.
Cheers,
Herve
-Original Message-
From: openembedded-core-boun...@lists.openembedded.org
[mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of
Ovidiu Panait
Sent: jeudi 14 juin 2018 13:55
To: openembedded-core@lists.openembedded.org
Subject: [OE-core] [PATCH 1/1] db: disable the ARM assembler mutex code
The swpb in macro MUTEX_SET will cause "undefined instruction" error on the
new arm arches which don't support this assembly instruction any more. If
use ldrex/strex to replace swpb, the old arm arches don't support them. So
to avoid this issue, just disable the ARM assembler mutex code, and use the
default pthreads mutex.
Signed-off-by: Li Zhou
Signed-off-by: Catalin Enache
Signed-off-by: Ovidiu Panait
---
meta/recipes-support/db/db_5.3.28.bb | 13 +
1 file changed, 1 insertion(+), 12 deletions(-)
diff --git a/meta/recipes-support/db/db_5.3.28.bb
b/meta/recipes-support/db/db_5.3.28.bb
index 093ee44909..15b4155a29 100644
--- a/meta/recipes-support/db/db_5.3.28.bb
+++ b/meta/recipes-support/db/db_5.3.28.bb
@@ -59,18 +59,7 @@ FILES_SOLIBSDEV = "${libdir}/libdb.so
${libdir}/libdb_cxx.so"
# All the --disable-* options replace --enable-smallbuild, which breaks a
bunch of stuff (eg. postfix) DB5_CONFIG ?= "--enable-o_direct
--disable-cryptography --disable-queue --disable-replication
--disable-verify --disable-compat185 --disable-sql"
-EXTRA_OECONF = "${DB5_CONFIG} --enable-shared --enable-cxx --with-sysroot"
-
-# Override the MUTEX setting here, the POSIX library is -# the default -
"POSIX/pthreads/library".
-# Don't ignore the nice SWP instruction on the ARM:
-# These enable the ARM assembler mutex code, this won't -# work with thumb
compilation...
-ARM_MUTEX = "--with-mutex=ARM/gcc-assembly"
-MUTEX = ""
-MUTEX_arm = "${ARM_MUTEX}"
-MUTEX_armeb = "${ARM_MUTEX}"
-EXTRA_OECONF += "${MUTEX} STRIP=true"
+EXTRA_OECONF = "${DB5_CONFIG} --enable-shared --enable-cxx --with-sysroot
STRIP=true"
EXTRA_OEMAKE += "LIBTOOL='./${HOST_SYS}-libtool'"
EXTRA_AUTORECONF += "--exclude=autoheader -I ${S}/dist/aclocal
-I${S}/dist/aclocal_java"
--
2.17.1
--
___
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 1/1] db: disable the ARM assembler mutex code
The swpb in macro MUTEX_SET will cause "undefined instruction" error
on the new arm arches which don't support this assembly instruction
any more. If use ldrex/strex to replace swpb, the old arm arches don't
support them. So to avoid this issue, just disable the ARM assembler
mutex code, and use the default pthreads mutex.
Signed-off-by: Li Zhou
Signed-off-by: Catalin Enache
Signed-off-by: Ovidiu Panait
---
meta/recipes-support/db/db_5.3.28.bb | 13 +
1 file changed, 1 insertion(+), 12 deletions(-)
diff --git a/meta/recipes-support/db/db_5.3.28.bb
b/meta/recipes-support/db/db_5.3.28.bb
index 093ee44909..15b4155a29 100644
--- a/meta/recipes-support/db/db_5.3.28.bb
+++ b/meta/recipes-support/db/db_5.3.28.bb
@@ -59,18 +59,7 @@ FILES_SOLIBSDEV = "${libdir}/libdb.so ${libdir}/libdb_cxx.so"
# All the --disable-* options replace --enable-smallbuild, which breaks a
bunch of stuff (eg. postfix)
DB5_CONFIG ?= "--enable-o_direct --disable-cryptography --disable-queue
--disable-replication --disable-verify --disable-compat185 --disable-sql"
-EXTRA_OECONF = "${DB5_CONFIG} --enable-shared --enable-cxx --with-sysroot"
-
-# Override the MUTEX setting here, the POSIX library is
-# the default - "POSIX/pthreads/library".
-# Don't ignore the nice SWP instruction on the ARM:
-# These enable the ARM assembler mutex code, this won't
-# work with thumb compilation...
-ARM_MUTEX = "--with-mutex=ARM/gcc-assembly"
-MUTEX = ""
-MUTEX_arm = "${ARM_MUTEX}"
-MUTEX_armeb = "${ARM_MUTEX}"
-EXTRA_OECONF += "${MUTEX} STRIP=true"
+EXTRA_OECONF = "${DB5_CONFIG} --enable-shared --enable-cxx --with-sysroot
STRIP=true"
EXTRA_OEMAKE += "LIBTOOL='./${HOST_SYS}-libtool'"
EXTRA_AUTORECONF += "--exclude=autoheader -I ${S}/dist/aclocal
-I${S}/dist/aclocal_java"
--
2.17.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/1] oeqa/runtime/cases/rpm.py: change to use base-passwd-doc
Right, I see. Thanks for explaining, the patch is fine then.
Alex
2018-06-14 12:31 GMT+03:00 ChenQi :
> Hi Alex,
>
> In short, it's about setUpClass.
> See details below.
>
> In fact, if rpm is not installed, these test cases have been skipped.
>
> See codes below from rpm.py:
>
> @OETestID(960)
> @OEHasPackage(['rpm'])
> @OETestDepends(['ssh.SSHTest.test_ssh'])
> def test_rpm_help(self):
> status, output = self.target.run('rpm --help')
> msg = 'status and output: %s and %s' % (status, output)
> self.assertEqual(status, 0, msg=msg)
>
> @OETestID(192)
> @OETestDepends(['rpm.RpmBasicTest.test_rpm_help'])
> def test_rpm_install(self):
> status, output = self.target.run('rpm -ivh
> /tmp/base-passwd-doc.rpm')
> msg = 'Failed to install base-passwd-doc package: %s' % output
> self.assertEqual(status, 0, msg=msg)
>
> You can see that if 'rpm' is not installed on target, the test cases are
> skipped.
> The '@skipIfNotFeature' decorator you suggested will achieve the same effect
> that the above logic has already achieved.
>
> The key problem here is that the copying action happens in setUpClass().
> Even if the testcase is determined to be skipped via the decorator logic,
> this setUpClass function will still be called.
>
> For the current OEQA's runtime testing design, we need to ensure setUpClass
> do not generate 'error'.
>
> For the problem I described in this email, the simplest approach I see here
> is to change rpm-doc to base-passwd-doc.
> Another apporach is to check whether 'rpm' is installed in setUpClass()
> function and if not skip. But this is more complex and kind of weird as
> we've checked it via @HasPackage and the test cases dependencies are
> correct.
>
> You can do a quick test with the following configuration to reproduce the
> problem.
> local.conf:
> IMAGE_INSTALL_append = " openssh"
> TEST_IMAGE = "1"
> TEST_SUITES = "auto"
>
> bitbake core-image-minimal
>
> Best Regards,
> Chen Qi
>
>
>
> On 06/14/2018 04:55 PM, Alexander Kanavin wrote:
>>
>> Hello Chen,
>>
>> But the test still attempts to run rpm on the target. I can't
>> understand how target rpm can be available on the image, but at the
>> same time target rpm-doc package is not available in rpm deploy dir.
>>
>> The issue is probably that the test should simply be skipped (in the
>> same way that dnf testcases are skipped - please refer to them), if
>> there is no package management on target? Like this:
>>
>> @skipIfNotFeature('package-management',
>>'Test requires package-management to be in
>> IMAGE_FEATURES')
>>
>>
>> Alex
>>
>> 2018-06-14 10:29 GMT+03:00 ChenQi :
>>>
>>> On 06/14/2018 02:57 PM, Alexander Kanavin wrote:
2018-06-14 7:52 GMT+03:00 Chen Qi :
>
> The test cases assume that rpm-doc is built out, as it says it its
> comment. This is not always true. And it sometimes results in
> following error.
>
> | cls.tc.target.copyTo(test_file, dst)
> | UnboundLocalError: local variable 'test_file' referenced before
> assignment
Wait, you need to explain this further. What is the situation when it
isn't true?
Alex
>>> Hi Alex,
>>>
>>> For any image that does not have rpm installed, rpm package is not likely
>>> to
>>> be built out.
>>> Having PACKAGE_CLASSES set to "package_rpm" will only ensure rpm-native
>>> to
>>> be built out.
>>>
>>> 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] Fix build error when enable archiver.
> -Original Message- > From: openembedded-core-boun...@lists.openembedded.org > [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of > Lei Maohui > Sent: den 2 juni 2018 23:04 > To: openembedded-core@lists.openembedded.org > Subject: [OE-core] [PATCH] Fix build error when enable archiver. > > The error is as fllowing: > ERROR: Task do_deploy_archives in > virtual:native:/yocto/poky/meta/recipes-extended/newt/libnewt_0.52.20.bb > depends upon non-existent task > do_package_write_rpm in > virtual:native:/yocto/poky/meta/recipes-extended/newt/libnewt_0.52.20.bb > ERROR: Command execution failed: 1 > > Signed-off-by: Lei Maohui > --- > meta/classes/nopackages.bbclass | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/meta/classes/nopackages.bbclass b/meta/classes/nopackages.bbclass > index 559f507..d9ddfac 100644 > --- a/meta/classes/nopackages.bbclass > +++ b/meta/classes/nopackages.bbclass > @@ -10,3 +10,4 @@ deltask do_package_write_ipk_setscene > deltask do_package_write_deb_setscene > deltask do_package_qa_setscene > deltask do_packagedata_setscene > +deltask do_deploy_archives > -- > 1.9.1 This cannot be correct. If I am not mistaken, then this would effectively disable the archiver class from outputting anything for native packages. //Peter -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] tune-ppce500v1: Add a tune file for PowerPC e500v1 cores
From: Chunrong Guo
Signed-off-by: Chunrong Guo
---
meta/conf/machine/include/tune-ppce500v1.inc | 20
1 file changed, 20 insertions(+)
create mode 100644 meta/conf/machine/include/tune-ppce500v1.inc
diff --git a/meta/conf/machine/include/tune-ppce500v1.inc
b/meta/conf/machine/include/tune-ppce500v1.inc
new file mode 100644
index 000..509c81b
--- /dev/null
+++ b/meta/conf/machine/include/tune-ppce500v1.inc
@@ -0,0 +1,20 @@
+DEFAULTTUNE ?= "ppce500v1"
+
+require conf/machine/include/powerpc/arch-powerpc.inc
+
+TUNEVALID[ppce500v1] = "Enable ppce500v1 specific processor optimizations"
+TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'ppce500v1', '
-mcpu=8540', '', d)}"
+
+TUNEVALID[spe] = "Enable SPE ABI extensions"
+TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', [ 'ppce500v1', 'spe' ],
' -mabi=spe -mspe -mfloat-gprs=double', '', d)}"
+TARGET_FPU .= "${@bb.utils.contains('TUNE_FEATURES', [ 'ppce500v1' , 'spe' ],
'ppc-efd', '', d)}"
+
+# spe is defined potentially in two places, so we want to be sure it will
+# only write spe once to the ABIEXTENSIONS field.
+SPEABIEXTENSION = "${@bb.utils.filter('TUNE_FEATURES', 'spe', d)}"
+ABIEXTENSION .= "${SPEABIEXTENSION}"
+
+AVAILTUNES += "ppce500v1"
+TUNE_FEATURES_tune-ppce500v1 = "m32 spe ppce500v1"
+TUNE_PKGARCH_tune-ppce500v1 = "ppce500v1"
+PACKAGE_EXTRA_ARCHS_tune-ppce500v1 = "ppce500v1"
--
2.7.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] ltp: set -fomit-frame-pointer explicitly
From: Mingli Yu
When build ltp with -fno-omit-frame-pointer,
it will trigger below error:
| cve-2015-3290.c: In function 'child_thread':
| cve-2015-3290.c:416:1: error: bp cannot be used in asm here
And there is also some comment as below in the source
file ltp/20180515-r0/git/testcases/cve/cve-2015-3290.c
* Build with -O2. Don't use -fno-omit-frame-pointer.
So explicitly set -fomit-frame-pointer for compiler
to fix the above build error.
Signed-off-by: Mingli Yu
---
meta/recipes-extended/ltp/ltp_20180515.bb | 4
1 file changed, 4 insertions(+)
diff --git a/meta/recipes-extended/ltp/ltp_20180515.bb
b/meta/recipes-extended/ltp/ltp_20180515.bb
index b07c1b9..5ec25ed 100644
--- a/meta/recipes-extended/ltp/ltp_20180515.bb
+++ b/meta/recipes-extended/ltp/ltp_20180515.bb
@@ -19,6 +19,10 @@ LIC_FILES_CHKSUM = "\
DEPENDS = "attr libaio libcap acl openssl zip-native"
DEPENDS_append_libc-musl = " fts "
EXTRA_OEMAKE_append_libc-musl = " LIBC=musl "
+
+# -fomit-frame-pointer to handle cases where optimisation is set to -O0 or
frame
+# pointers have been enabled by -fno-omit-frame-pointer earlier in CFLAGS, etc.
+CFLAGS_append = " ${@bb.utils.contains('SELECTED_OPTIMIZATION',
'-fno-omit-frame-pointer', '-fomit-frame-pointer', '', d)}"
CFLAGS_append_powerpc64 = " -D__SANE_USERSPACE_TYPES__"
CFLAGS_append_mipsarchn64 = " -D__SANE_USERSPACE_TYPES__"
SRCREV = "96cbf48313afa65ef4d693d3441cbfd60a8d9b27"
--
2.7.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/1] oeqa/runtime/cases/rpm.py: change to use base-passwd-doc
Hi Alex,
In short, it's about setUpClass.
See details below.
In fact, if rpm is not installed, these test cases have been skipped.
See codes below from rpm.py:
@OETestID(960)
@OEHasPackage(['rpm'])
@OETestDepends(['ssh.SSHTest.test_ssh'])
def test_rpm_help(self):
status, output = self.target.run('rpm --help')
msg = 'status and output: %s and %s' % (status, output)
self.assertEqual(status, 0, msg=msg)
@OETestID(192)
@OETestDepends(['rpm.RpmBasicTest.test_rpm_help'])
def test_rpm_install(self):
status, output = self.target.run('rpm -ivh
/tmp/base-passwd-doc.rpm')
msg = 'Failed to install base-passwd-doc package: %s' % output
self.assertEqual(status, 0, msg=msg)
You can see that if 'rpm' is not installed on target, the test cases are
skipped.
The '@skipIfNotFeature' decorator you suggested will achieve the same
effect that the above logic has already achieved.
The key problem here is that the copying action happens in setUpClass().
Even if the testcase is determined to be skipped via the decorator
logic, this setUpClass function will still be called.
For the current OEQA's runtime testing design, we need to ensure
setUpClass do not generate 'error'.
For the problem I described in this email, the simplest approach I see
here is to change rpm-doc to base-passwd-doc.
Another apporach is to check whether 'rpm' is installed in setUpClass()
function and if not skip. But this is more complex and kind of weird as
we've checked it via @HasPackage and the test cases dependencies are
correct.
You can do a quick test with the following configuration to reproduce
the problem.
local.conf:
IMAGE_INSTALL_append = " openssh"
TEST_IMAGE = "1"
TEST_SUITES = "auto"
bitbake core-image-minimal
Best Regards,
Chen Qi
On 06/14/2018 04:55 PM, Alexander Kanavin wrote:
Hello Chen,
But the test still attempts to run rpm on the target. I can't
understand how target rpm can be available on the image, but at the
same time target rpm-doc package is not available in rpm deploy dir.
The issue is probably that the test should simply be skipped (in the
same way that dnf testcases are skipped - please refer to them), if
there is no package management on target? Like this:
@skipIfNotFeature('package-management',
'Test requires package-management to be in
IMAGE_FEATURES')
Alex
2018-06-14 10:29 GMT+03:00 ChenQi :
On 06/14/2018 02:57 PM, Alexander Kanavin wrote:
2018-06-14 7:52 GMT+03:00 Chen Qi :
The test cases assume that rpm-doc is built out, as it says it its
comment. This is not always true. And it sometimes results in
following error.
| cls.tc.target.copyTo(test_file, dst)
| UnboundLocalError: local variable 'test_file' referenced before
assignment
Wait, you need to explain this further. What is the situation when it
isn't true?
Alex
Hi Alex,
For any image that does not have rpm installed, rpm package is not likely to
be built out.
Having PACKAGE_CLASSES set to "package_rpm" will only ensure rpm-native to
be built out.
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 1/1] oeqa/runtime/cases/rpm.py: change to use base-passwd-doc
Hello Chen,
But the test still attempts to run rpm on the target. I can't
understand how target rpm can be available on the image, but at the
same time target rpm-doc package is not available in rpm deploy dir.
The issue is probably that the test should simply be skipped (in the
same way that dnf testcases are skipped - please refer to them), if
there is no package management on target? Like this:
@skipIfNotFeature('package-management',
'Test requires package-management to be in
IMAGE_FEATURES')
Alex
2018-06-14 10:29 GMT+03:00 ChenQi :
> On 06/14/2018 02:57 PM, Alexander Kanavin wrote:
>>
>> 2018-06-14 7:52 GMT+03:00 Chen Qi :
>>>
>>> The test cases assume that rpm-doc is built out, as it says it its
>>> comment. This is not always true. And it sometimes results in
>>> following error.
>>>
>>>| cls.tc.target.copyTo(test_file, dst)
>>>| UnboundLocalError: local variable 'test_file' referenced before
>>> assignment
>>
>> Wait, you need to explain this further. What is the situation when it
>> isn't true?
>>
>> Alex
>>
>
> Hi Alex,
>
> For any image that does not have rpm installed, rpm package is not likely to
> be built out.
> Having PACKAGE_CLASSES set to "package_rpm" will only ensure rpm-native to
> be built out.
>
> 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] matchbox-terminal: Update commitID
Hi Richard, Ross
> Message: 2
> Date: Mon, 11 Jun 2018 14:39:53 +0100
> From: Richard Purdie
> To: Devarsh Thakkar ,
> "openembedded-core@lists.openembedded.org"
>
> Cc: Maulik Desai ,Varunkumar Allagadapa
>
> Subject: Re: [OE-core] [PATCH] matchbox-terminal: Update commitID
> Message-ID:
> <642b938d82295e3b7ce922dad711c63904d62ca5.camel@linuxfounda
> tion.org>
> Content-Type: text/plain; charset="UTF-8"
>
> On Mon, 2018-06-11 at 12:39 +, Devarsh Thakkar wrote:
> > Hi Richard,
> >
> > Thanks for the quick review.
> > Replies inline.
> >
> > > Message: 5
> > > Date: Sun, 10 Jun 2018 09:29:14 +0100
> > > From: Richard Purdie
> > > To: Devarsh Thakkar ,
> > > openembedded-core@lists.openembedded.org
> > > Cc: maul...@xilinx.com, varun...@xilinx.com, jae...@xilinx.com,
> > > Devarsh Thakkar
> > > Subject: Re: [OE-core] [PATCH] matchbox-terminal: Update commitID
> > > Message-ID:
> > > <56788cd154d9af0b6c9ea2ef78de23b1909fd7ee.camel@linuxfoundati
> > > on.org>
> > > Content-Type: text/plain; charset="UTF-8"
> > >
> > > On Sat, 2018-06-09 at 04:59 -0700, Devarsh Thakkar wrote:
> > > > Pull in change which adds support for command line
> > > > options (-e and --command) which can be used for
> > > > launching programs or running commands in matchbox-terminal
> > > > via command line.
> > > >
> > > > Signed-off-by: Devarsh Thakkar
> > > > ---
> > > > meta/recipes-sato/matchbox-terminal/matchbox-terminal_0.1.bb | 2
> > > > +-
> > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > >
> > > > diff --git a/meta/recipes-sato/matchbox-terminal/matchbox-
> > > > terminal_0.1.bb b/meta/recipes-sato/matchbox-terminal/matchbox-
> > > > terminal_0.1.bb
> > > > index 4488191..b7fbee7 100644
> > > > --- a/meta/recipes-sato/matchbox-terminal/matchbox-
> > > > terminal_0.1.bb
> > > > +++ b/meta/recipes-sato/matchbox-terminal/matchbox-
> > > > terminal_0.1.bb
> > > > @@ -10,7 +10,7 @@ DEPENDS = "gtk+3 vte"
> > > > SECTION = "x11/utils"
> > > >
> > > > #SRCREV tagged 0.1
> > >
> > > I'm guessing the above comment is no longer valid, nor is the value
> > > of
> > > PV?
> >
> > Yes the comment is no longer valid I will remove that in V2.
> > But the PV is still valid as matchbox-terminal package version is
> > still 0.1 ( as set in AC_INIT at http://git.yoctoproject.org/cgit.cgi
> > /matchbox-terminal/tree/configure.ac) even after this commit.
>
> No, after your change its not the 0.1 release, its 0.1+git,
> its a different version sometime after 0.1.
Thanks for sharing, I got your point. I guess there are below possible
solutions here :
1) set PV="${BPV}+gitr${SRCPV}" were BPV=0.1
2) move the tag 0.1 to ccbc3c70946b04313c6166ab0dfef21e5e83c289 for
matchbox-terminal
3) Update a new tag at 0.2 at to ccbc3c70946b04313c6166ab0dfef21e5e83c289
Kindly let me know which of the above is preferred way.
Thanks,
Devarsh
>
> Cheers,
>
> Richard
>
>
> --
>
> Message: 3
> Date: Mon, 11 Jun 2018 12:39:20 +
> From: Devarsh Thakkar
> To: "openembedded-core@lists.openembedded.org"
> ,
> "richard.pur...@linuxfoundation.org"
>
> Cc: Maulik Desai ,Varunkumar Allagadapa
>
> Subject: Re: [OE-core] [PATCH] matchbox-terminal: Update commitID
> Message-ID:
>amprd02.prod.outlook.com>
>
> Content-Type: text/plain; charset="us-ascii"
>
> Hi Richard,
>
> Thanks for the quick review.
> Replies inline.
>
> > Message: 5
> > Date: Sun, 10 Jun 2018 09:29:14 +0100
> > From: Richard Purdie
> > To: Devarsh Thakkar ,
> > openembedded-core@lists.openembedded.org
> > Cc: maul...@xilinx.com, varun...@xilinx.com, jae...@xilinx.com,
> > Devarsh Thakkar
> > Subject: Re: [OE-core] [PATCH] matchbox-terminal: Update commitID
> > Message-ID:
> > <56788cd154d9af0b6c9ea2ef78de23b1909fd7ee.camel@linuxfoundati
> > on.org>
> > Content-Type: text/plain; charset="UTF-8"
> >
> > On Sat, 2018-06-09 at 04:59 -0700, Devarsh Thakkar wrote:
> > > Pull in change which adds support for command line
> > > options (-e and --command) which can be used for
> > > launching programs or running commands in matchbox-terminal
> > > via command line.
> > >
> > > Signed-off-by: Devarsh Thakkar
> > > ---
> > > meta/recipes-sato/matchbox-terminal/matchbox-terminal_0.1.bb | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/meta/recipes-sato/matchbox-terminal/matchbox-
> > > terminal_0.1.bb b/meta/recipes-sato/matchbox-terminal/matchbox-
> > > terminal_0.1.bb
> > > index 4488191..b7fbee7 100644
> > > --- a/meta/recipes-sato/matchbox-terminal/matchbox-terminal_0.1.bb
> > > +++ b/meta/recipes-sato/matchbox-terminal/matchbox-terminal_0.1.bb
> > > @@ -10,7 +10,7 @@ DEPENDS = "gtk+3 vte"
> > > SECTION = "x11/utils"
> > >
> > > #SRCREV tagged 0.1
> >
> > I'm guessing the above comment is no longer valid, nor is the value of
> > PV?
> Yes the comment is no longer valid I will remove that in V2.
> But the PV is still valid
[OE-core] [PATCH v3] sqlite3: upgrade to 3.24.0
Provide a new packageconfig for fts5 support.
Signed-off-by: Maxin B. John
---
meta/recipes-support/sqlite/sqlite3.inc | 1 +
meta/recipes-support/sqlite/{sqlite3_3.23.1.bb => sqlite3_3.24.0.bb} | 4 ++--
2 files changed, 3 insertions(+), 2 deletions(-)
rename meta/recipes-support/sqlite/{sqlite3_3.23.1.bb => sqlite3_3.24.0.bb}
(59%)
diff --git a/meta/recipes-support/sqlite/sqlite3.inc
b/meta/recipes-support/sqlite/sqlite3.inc
index 95ec89c..1aab970 100644
--- a/meta/recipes-support/sqlite/sqlite3.inc
+++ b/meta/recipes-support/sqlite/sqlite3.inc
@@ -26,6 +26,7 @@ PACKAGECONFIG_class-native = ""
PACKAGECONFIG[editline] = "--enable-editline,--disable-editline,libedit"
PACKAGECONFIG[readline] = "--enable-readline,--disable-readline,readline
ncurses"
+PACKAGECONFIG[fts5] = "--enable-fts5,--enable-fts5=no,"
EXTRA_OECONF = " \
--enable-shared \
diff --git a/meta/recipes-support/sqlite/sqlite3_3.23.1.bb
b/meta/recipes-support/sqlite/sqlite3_3.24.0.bb
similarity index 59%
rename from meta/recipes-support/sqlite/sqlite3_3.23.1.bb
rename to meta/recipes-support/sqlite/sqlite3_3.24.0.bb
index 3755761..ce18fec 100644
--- a/meta/recipes-support/sqlite/sqlite3_3.23.1.bb
+++ b/meta/recipes-support/sqlite/sqlite3_3.24.0.bb
@@ -6,5 +6,5 @@ LIC_FILES_CHKSUM =
"file://sqlite3.h;endline=11;md5=786d3dc581eff03f4fd9e4a77ed0
SRC_URI = "\
http://www.sqlite.org/2018/sqlite-autoconf-${SQLITE_PV}.tar.gz \
"
-SRC_URI[md5sum] = "99a51b40a66872872a91c92f6d0134fa"
-SRC_URI[sha256sum] =
"92842b283e5e744eff5da29ed3c69391de7368fccc4d0ee6bf62490ce555ef25"
+SRC_URI[md5sum] = "dcd96fb9bbb603d29f6b0ad9554932ee"
+SRC_URI[sha256sum] =
"d9d14e88c6fb6d68de9ca0d1f9797477d82fc3aed613558f87ffbdbbc5ceb74a"
--
2.4.0
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v2] sqlite3: upgrade to 3.24.0
Hi Khem,
On Wed, Jun 13, 2018 at 08:37:14AM -0700, Khem Raj wrote:
> Hi Maxin
>
> On 6/13/18 7:54 AM, Maxin B. John wrote:
> >Disable fts5 support as it causes build errors for pseudo.
> >
> >Signed-off-by: Maxin B. John
> >---
> > meta/recipes-support/sqlite/sqlite3.inc | 1 +
> > meta/recipes-support/sqlite/{sqlite3_3.23.1.bb => sqlite3_3.24.0.bb} | 4
> > ++--
> > 2 files changed, 3 insertions(+), 2 deletions(-)
> > rename meta/recipes-support/sqlite/{sqlite3_3.23.1.bb =>
> > sqlite3_3.24.0.bb} (59%)
> >
> >diff --git a/meta/recipes-support/sqlite/sqlite3.inc
> >b/meta/recipes-support/sqlite/sqlite3.inc
> >index 95ec89c..7312c84 100644
> >--- a/meta/recipes-support/sqlite/sqlite3.inc
> >+++ b/meta/recipes-support/sqlite/sqlite3.inc
> >@@ -31,6 +31,7 @@ EXTRA_OECONF = " \
> > --enable-shared \
> > --enable-threadsafe \
> > --disable-static-shell \
> >+--enable-fts5=no \
> > "
>
> is this causing issues for pseudo target recipe ?
> perhaps its better to turn it into a packageconfig
Ok, Will do that.
> > CFLAGS_append = " -fPIC"
> >diff --git a/meta/recipes-support/sqlite/sqlite3_3.23.1.bb
> >b/meta/recipes-support/sqlite/sqlite3_3.24.0.bb
> >similarity index 59%
> >rename from meta/recipes-support/sqlite/sqlite3_3.23.1.bb
> >rename to meta/recipes-support/sqlite/sqlite3_3.24.0.bb
> >index 3755761..ce18fec 100644
> >--- a/meta/recipes-support/sqlite/sqlite3_3.23.1.bb
> >+++ b/meta/recipes-support/sqlite/sqlite3_3.24.0.bb
> >@@ -6,5 +6,5 @@ LIC_FILES_CHKSUM =
> >"file://sqlite3.h;endline=11;md5=786d3dc581eff03f4fd9e4a77ed0
> > SRC_URI = "\
> >http://www.sqlite.org/2018/sqlite-autoconf-${SQLITE_PV}.tar.gz \
> >"
> >-SRC_URI[md5sum] = "99a51b40a66872872a91c92f6d0134fa"
> >-SRC_URI[sha256sum] =
> >"92842b283e5e744eff5da29ed3c69391de7368fccc4d0ee6bf62490ce555ef25"
> >+SRC_URI[md5sum] = "dcd96fb9bbb603d29f6b0ad9554932ee"
> >+SRC_URI[sha256sum] =
> >"d9d14e88c6fb6d68de9ca0d1f9797477d82fc3aed613558f87ffbdbbc5ceb74a"
Best Regards,
Maxin
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/1] oeqa/runtime/cases/rpm.py: change to use base-passwd-doc
On 06/14/2018 02:57 PM, Alexander Kanavin wrote: 2018-06-14 7:52 GMT+03:00 Chen Qi : The test cases assume that rpm-doc is built out, as it says it its comment. This is not always true. And it sometimes results in following error. | cls.tc.target.copyTo(test_file, dst) | UnboundLocalError: local variable 'test_file' referenced before assignment Wait, you need to explain this further. What is the situation when it isn't true? Alex Hi Alex, For any image that does not have rpm installed, rpm package is not likely to be built out. Having PACKAGE_CLASSES set to "package_rpm" will only ensure rpm-native to be built out. 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] meta-toolchain: Added dnf-nativesdk into cross-development toolchain.
2018-06-14 6:38 GMT+03:00 Zheng, Ruoqin : > I submitted this patch aim to use dnf out of Yocto build system to manage > packages. Please explain this in detail. Where are the packages taken from, and where are they installed? Alex -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
