[OE-core] [PATCH] dmidecode: add powerpc64 to compatible host
From: Jackie Huang
Signed-off-by: Jackie Huang
---
meta/recipes-devtools/dmidecode/dmidecode_2.12.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-devtools/dmidecode/dmidecode_2.12.bb
b/meta/recipes-devtools/dmidecode/dmidecode_2.12.bb
index 3e3a350..b5151b8 100644
--- a/meta/recipes-devtools/dmidecode/dmidecode_2.12.bb
+++ b/meta/recipes-devtools/dmidecode/dmidecode_2.12.bb
@@ -5,7 +5,7 @@ LIC_FILES_CHKSUM =
"file://LICENSE;md5=393a5ca445f6965873eca0259a17f833"
SRC_URI = "${SAVANNAH_NONGNU_MIRROR}/dmidecode/${BP}.tar.bz2"
-COMPATIBLE_HOST = "(i.86|x86_64|aarch64|arm|powerpc).*-linux"
+COMPATIBLE_HOST = "(i.86|x86_64|aarch64|arm|powerpc|powerpc64).*-linux"
do_install() {
oe_runmake DESTDIR="${D}" install
--
1.9.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH v2] u-boot: update to version 2015.01
From: Denys Dmytriyenko
Signed-off-by: Denys Dmytriyenko
---
v2 - rebase on top of fw-utils combining patch from Otavio
.../0001-tools-env-fix-build-error.patch | 36 ++
...utils_2014.07.bb => u-boot-fw-utils_2015.01.bb} | 21 +++--
...kimage_2014.07.bb => u-boot-mkimage_2015.01.bb} | 20 ++--
meta/recipes-bsp/u-boot/u-boot.inc | 2 +-
.../{u-boot_2014.07.bb => u-boot_2015.01.bb} | 6 ++--
5 files changed, 61 insertions(+), 24 deletions(-)
create mode 100644
meta/recipes-bsp/u-boot/u-boot-fw-utils/0001-tools-env-fix-build-error.patch
rename meta/recipes-bsp/u-boot/{u-boot-fw-utils_2014.07.bb =>
u-boot-fw-utils_2015.01.bb} (58%)
rename meta/recipes-bsp/u-boot/{u-boot-mkimage_2014.07.bb =>
u-boot-mkimage_2015.01.bb} (45%)
rename meta/recipes-bsp/u-boot/{u-boot_2014.07.bb => u-boot_2015.01.bb} (50%)
diff --git
a/meta/recipes-bsp/u-boot/u-boot-fw-utils/0001-tools-env-fix-build-error.patch
b/meta/recipes-bsp/u-boot/u-boot-fw-utils/0001-tools-env-fix-build-error.patch
new file mode 100644
index 000..381b505
--- /dev/null
+++
b/meta/recipes-bsp/u-boot/u-boot-fw-utils/0001-tools-env-fix-build-error.patch
@@ -0,0 +1,36 @@
+From ee2d75513452aa6d5306fd380104adc8a2f6d8f2 Mon Sep 17 00:00:00 2001
+From: Masahiro Yamada
+Date: Wed, 3 Dec 2014 10:22:50 +0900
+Subject: [PATCH] tools: env: fix build error
+
+Since CONFIG_SYS_ARCH, CONFIG_SYS_CPU, ... were moved to Kconfig,
+tools/env/fw_printenv fails to build if CONFIG_ENV_VARS_UBOOT_CONFIG
+is defined.
+(I do not think this is the right way to fix the problem, but
+for now I do not have enough time to take a close look.)
+
+Upstream-Status: Submitted [http://patchwork.ozlabs.org/patch/417192/]
+
+Signed-off-by: Masahiro Yamada
+Reported-by: Denys Dmytriyenko
+---
+ tools/env/fw_env.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+diff --git a/tools/env/fw_env.c b/tools/env/fw_env.c
+index 1173eea..698fe51 100644
+--- a/tools/env/fw_env.c
b/tools/env/fw_env.c
+@@ -8,6 +8,9 @@
+ * SPDX-License-Identifier: GPL-2.0+
+ */
+
++/* FIXME: Do not include this */
++#include
++
+ #include
+ #include
+ #include
+--
+2.2.0
+
diff --git a/meta/recipes-bsp/u-boot/u-boot-fw-utils_2014.07.bb
b/meta/recipes-bsp/u-boot/u-boot-fw-utils_2015.01.bb
similarity index 58%
rename from meta/recipes-bsp/u-boot/u-boot-fw-utils_2014.07.bb
rename to meta/recipes-bsp/u-boot/u-boot-fw-utils_2015.01.bb
index 9a304c8..17453ca 100644
--- a/meta/recipes-bsp/u-boot/u-boot-fw-utils_2014.07.bb
+++ b/meta/recipes-bsp/u-boot/u-boot-fw-utils_2015.01.bb
@@ -1,21 +1,24 @@
SUMMARY = "U-Boot bootloader fw_printenv/setenv utilities"
LICENSE = "GPLv2+"
-LIC_FILES_CHKSUM =
"file://Licenses/README;md5=025bf9f768cbcb1a165dbe1a110babfb"
+LIC_FILES_CHKSUM =
"file://Licenses/README;md5=c7383a594871c03da76b3707929d2919"
SECTION = "bootloader"
DEPENDS = "mtd-utils"
-# This revision corresponds to the tag "v2014.07"
+# This revision corresponds to the tag "v2015.01"
# We use the revision in order to avoid having to fetch it from the
# repo during parse
-SRCREV = "524123a70761110c5cf3ccc5f52f6d4da071b959"
+SRCREV = "92fa7f53f1f3f03296f8ffb14bdf1baefab83368"
-PV = "v2014.07+git${SRCPV}"
+PV = "v2015.01+git${SRCPV}"
-SRC_URI = "git://git.denx.de/u-boot.git;branch=master;protocol=git"
+SRC_URI = "git://git.denx.de/u-boot.git;branch=master;protocol=git \
+ file://0001-tools-env-fix-build-error.patch"
S = "${WORKDIR}/git"
INSANE_SKIP_${PN} = "already-stripped"
+EXTRA_OEMAKE_class-target = 'CROSS_COMPILE=${TARGET_PREFIX} CC="${CC}"'
+EXTRA_OEMAKE_class-cross = 'ARCH=${TARGET_ARCH}'
inherit uboot-config
@@ -33,14 +36,14 @@ do_install () {
}
do_install_class-cross () {
-install -d ${D}${bindir_cross}
-install -m 755 ${S}/tools/env/fw_printenv ${D}${bindir_cross}/fw_printenv
-install -m 755 ${S}/tools/env/fw_printenv ${D}${bindir_cross}/fw_setenv
+ install -d ${D}${bindir_cross}
+ install -m 755 ${S}/tools/env/fw_printenv
${D}${bindir_cross}/fw_printenv
+ install -m 755 ${S}/tools/env/fw_printenv ${D}${bindir_cross}/fw_setenv
}
SYSROOT_PREPROCESS_FUNCS_class-cross = "uboot_fw_utils_cross"
uboot_fw_utils_cross() {
-sysroot_stage_dir ${D}${bindir_cross} ${SYSROOT_DESTDIR}${bindir_cross}
+ sysroot_stage_dir ${D}${bindir_cross} ${SYSROOT_DESTDIR}${bindir_cross}
}
PACKAGE_ARCH = "${MACHINE_ARCH}"
diff --git a/meta/recipes-bsp/u-boot/u-boot-mkimage_2014.07.bb
b/meta/recipes-bsp/u-boot/u-boot-mkimage_2015.01.bb
similarity index 45%
rename from meta/recipes-bsp/u-boot/u-boot-mkimage_2014.07.bb
rename to meta/recipes-bsp/u-boot/u-boot-mkimage_2015.01.bb
index eabf680..1bfdf9d 100644
--- a/meta/recipes-bsp/u-boot/u-boot-mkimage_2014.07.bb
+++ b/meta/recipes-bsp/u-boot/u-boot-mkimage_2015.01.bb
@@ -1,28 +1,26 @@
SUMMARY = "U-Boot bootloader image creation tool"
LICENSE = "GPLv2+"
-LIC_FILES_CHKSUM =
"file://Licenses/README;md5=025bf9f768cbcb1a165dbe1a1
Re: [OE-core] [PATCH] arch-mips.inc: Change definition of TRANSLATED_TARGET_ARCH
Note, I tested this by building a world build for MACHINE qemumips64 with DEFAULTTUNE set to mips64-n32. It and the other recent patches I've sent are available at git://git.yoctoproject.org/poky-contrib mhatle/oe-core --Mark On 1/23/15 3:20 PM, Mark Hatle wrote: > [YOCTO #7230] > > In certain system configurations TRANSLATED_TARGET_ARCH will not > expand in the right order for gcc-cross-candian-mips64n32 to be > generated properly. > > This will cause SDKs to fail to generate properly. > > Changing the global definition of TRANSLATED_TARGET_ARCH always > expands the ABIEXTENSION, which causes the OVERRIDES to pick it up > as well. This effectively defines a new class of overrides for the 'n32'. > > The side effect is that we need to duplicate some mips64 overrides, and > redefine others that were previously 'n32' or 'mips64' exclusive to have > the correct semantics. > > Signed-off-by: Mark Hatle > --- > meta/conf/bitbake.conf | 2 + > meta/conf/machine/include/mips/arch-mips.inc | 4 +- > .../packagegroups/packagegroup-core-sdk.bb | 1 + > .../packagegroup-core-tools-profile.bb | 2 + > .../packagegroups/packagegroup-self-hosted.bb | 1 + > meta/recipes-devtools/gcc/gcc-configure-common.inc | 2 + > meta/recipes-devtools/gdb/gdb-common.inc | 2 + > .../python/python-numpy/mips64n32/_numpyconfig.h | 30 + > .../python/python-numpy/mips64n32/config.h | 139 > + > meta/recipes-devtools/python/python-numpy_1.7.0.bb | 4 + > .../ghostscript/ghostscript/mips64eln32/objarch.h | 40 ++ > .../ghostscript/ghostscript/mips64n32/objarch.h| 40 ++ > meta/recipes-extended/mdadm/mdadm_3.3.2.bb | 1 + > .../packagegroups/packagegroup-core-lsb.bb | 1 + > meta/recipes-kernel/sysprof/sysprof_git.bb | 1 + > .../packagegroups/packagegroup-core-qt.bb | 2 +- > .../packagegroups/packagegroup-core-qt4e.bb| 2 +- > .../packagegroup-qt-toolchain-target.inc | 2 +- > meta/recipes-qt/qt4/qt4-4.8.6.inc | 2 +- > meta/recipes-sato/images/core-image-sato-sdk.bb| 1 + > meta/recipes-sato/midori/midori_0.5.8.bb | 2 +- > meta/recipes-sato/webkit/webkit-gtk_1.8.3.bb | 2 +- > 22 files changed, 276 insertions(+), 7 deletions(-) > create mode 100644 > meta/recipes-devtools/python/python-numpy/mips64n32/_numpyconfig.h > create mode 100644 > meta/recipes-devtools/python/python-numpy/mips64n32/config.h > create mode 100644 > meta/recipes-extended/ghostscript/ghostscript/mips64eln32/objarch.h > create mode 100644 > meta/recipes-extended/ghostscript/ghostscript/mips64n32/objarch.h -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] arch-mips.inc: Change definition of TRANSLATED_TARGET_ARCH
[YOCTO #7230]
In certain system configurations TRANSLATED_TARGET_ARCH will not
expand in the right order for gcc-cross-candian-mips64n32 to be
generated properly.
This will cause SDKs to fail to generate properly.
Changing the global definition of TRANSLATED_TARGET_ARCH always
expands the ABIEXTENSION, which causes the OVERRIDES to pick it up
as well. This effectively defines a new class of overrides for the 'n32'.
The side effect is that we need to duplicate some mips64 overrides, and
redefine others that were previously 'n32' or 'mips64' exclusive to have
the correct semantics.
Signed-off-by: Mark Hatle
---
meta/conf/bitbake.conf | 2 +
meta/conf/machine/include/mips/arch-mips.inc | 4 +-
.../packagegroups/packagegroup-core-sdk.bb | 1 +
.../packagegroup-core-tools-profile.bb | 2 +
.../packagegroups/packagegroup-self-hosted.bb | 1 +
meta/recipes-devtools/gcc/gcc-configure-common.inc | 2 +
meta/recipes-devtools/gdb/gdb-common.inc | 2 +
.../python/python-numpy/mips64n32/_numpyconfig.h | 30 +
.../python/python-numpy/mips64n32/config.h | 139 +
meta/recipes-devtools/python/python-numpy_1.7.0.bb | 4 +
.../ghostscript/ghostscript/mips64eln32/objarch.h | 40 ++
.../ghostscript/ghostscript/mips64n32/objarch.h| 40 ++
meta/recipes-extended/mdadm/mdadm_3.3.2.bb | 1 +
.../packagegroups/packagegroup-core-lsb.bb | 1 +
meta/recipes-kernel/sysprof/sysprof_git.bb | 1 +
.../packagegroups/packagegroup-core-qt.bb | 2 +-
.../packagegroups/packagegroup-core-qt4e.bb| 2 +-
.../packagegroup-qt-toolchain-target.inc | 2 +-
meta/recipes-qt/qt4/qt4-4.8.6.inc | 2 +-
meta/recipes-sato/images/core-image-sato-sdk.bb| 1 +
meta/recipes-sato/midori/midori_0.5.8.bb | 2 +-
meta/recipes-sato/webkit/webkit-gtk_1.8.3.bb | 2 +-
22 files changed, 276 insertions(+), 7 deletions(-)
create mode 100644
meta/recipes-devtools/python/python-numpy/mips64n32/_numpyconfig.h
create mode 100644 meta/recipes-devtools/python/python-numpy/mips64n32/config.h
create mode 100644
meta/recipes-extended/ghostscript/ghostscript/mips64eln32/objarch.h
create mode 100644
meta/recipes-extended/ghostscript/ghostscript/mips64n32/objarch.h
diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
index d22e9e8..ba6113d 100644
--- a/meta/conf/bitbake.conf
+++ b/meta/conf/bitbake.conf
@@ -520,6 +520,8 @@ LINKER_HASH_STYLE_mips = "sysv"
LINKER_HASH_STYLE_mipsel = "sysv"
LINKER_HASH_STYLE_mips64 = "sysv"
LINKER_HASH_STYLE_mips64el = "sysv"
+LINKER_HASH_STYLE_mips64n32 = "sysv"
+LINKER_HASH_STYLE_mips64eln32 = "sysv"
TARGET_LINK_HASH_STYLE ?=
"${@['-Wl,--hash-style=gnu',''][d.getVar('LINKER_HASH_STYLE', True) != 'gnu']}"
export LDFLAGS = "${TARGET_LDFLAGS}"
diff --git a/meta/conf/machine/include/mips/arch-mips.inc
b/meta/conf/machine/include/mips/arch-mips.inc
index 08d8fdc..c41fa5e 100644
--- a/meta/conf/machine/include/mips/arch-mips.inc
+++ b/meta/conf/machine/include/mips/arch-mips.inc
@@ -101,4 +101,6 @@ BASE_LIB_tune-mips64el-nf = "lib64"
MIPSPKGSFX_VARIANT_tune-mips64el-nf = "${TUNE_ARCH}"
PACKAGE_EXTRA_ARCHS_tune-mips64el-nf = "mips64el-nf"
-TRANSLATED_TARGET_ARCH_append = "${ABIEXTENSION}"
+# On mips we need to redefine this to include the ABIEXTENSION
+# we can avoid the python bit as there are no _ or - to translate
+TRANSLATED_TARGET_ARCH = "${TARGET_ARCH}${ABIEXTENSION}"
diff --git a/meta/recipes-core/packagegroups/packagegroup-core-sdk.bb
b/meta/recipes-core/packagegroups/packagegroup-core-sdk.bb
index 83da7e0..a41eada 100644
--- a/meta/recipes-core/packagegroups/packagegroup-core-sdk.bb
+++ b/meta/recipes-core/packagegroups/packagegroup-core-sdk.bb
@@ -32,6 +32,7 @@ SANITIZERS = "libasan-dev libubsan-dev"
SANITIZERS_aarch64 = ""
SANITIZERS_mips = ""
SANITIZERS_mips64 = ""
+SANITIZERS_mips64n32 = ""
SANITIZERS_powerpc64 = ""
SANITIZERS_sparc = ""
diff --git a/meta/recipes-core/packagegroups/packagegroup-core-tools-profile.bb
b/meta/recipes-core/packagegroups/packagegroup-core-tools-profile.bb
index f0ba8b9..6f4842f 100644
--- a/meta/recipes-core/packagegroups/packagegroup-core-tools-profile.bb
+++ b/meta/recipes-core/packagegroups/packagegroup-core-tools-profile.bb
@@ -38,6 +38,7 @@ SYSTEMTAP = "systemtap"
SYSTEMTAP_libc-uclibc = ""
SYSTEMTAP_mips = ""
SYSTEMTAP_mips64 = ""
+SYSTEMTAP_mips64n32 = ""
SYSTEMTAP_aarch64 = ""
# lttng-ust uses sched_getcpu() which is not there on uclibc
@@ -65,6 +66,7 @@ VALGRIND = "valgrind"
VALGRIND_libc-uclibc = ""
VALGRIND_mips = ""
VALGRIND_mips64 = ""
+VALGRIND_mips64n32 = ""
VALGRIND_arm = ""
VALGRIND_aarch64 = ""
diff --git a/meta/recipes-core/packagegroups/packagegroup-self-hosted.bb
b/meta/recipes-core/packagegroups/packagegroup-self-hosted.bb
index af57fac..c471020 100644
--- a/meta/recipes-core/packagegroups/package
Re: [OE-core] [PATCH] u-boot-fw-utils: Fix the cross build
On Thu, Jan 22, 2015 at 10:55:07PM -0500, Denys Dmytriyenko wrote:
> On Thu, Jan 22, 2015 at 11:18:27PM -0200, Otavio Salvador wrote:
> > This merges the u-boot-fw-utils-cross into the main u-boot-fw-utils
> > recipe and fixes the build failure seen since 2014.07 update.
>
> So, the actual fix is to drop unnecessary EXTRA_OEMAKE that you had there
> from
> the beginning of time... Combining it with target recipe is icing on the cake.
Well, that worked for 2014.07, but breaks now for 2015.01 :(
Looking at it now...
> > The cross package now is handled using an extended class instead of a
> > duplicated recipe.
> >
> > Signed-off-by: Otavio Salvador
> > ---
> > .../u-boot/u-boot-fw-utils-cross_2014.07.bb| 38
> > --
> > meta/recipes-bsp/u-boot/u-boot-fw-utils_2014.07.bb | 12 +++
> > 2 files changed, 12 insertions(+), 38 deletions(-)
> > delete mode 100644 meta/recipes-bsp/u-boot/u-boot-fw-utils-cross_2014.07.bb
> >
> > diff --git a/meta/recipes-bsp/u-boot/u-boot-fw-utils-cross_2014.07.bb
> > b/meta/recipes-bsp/u-boot/u-boot-fw-utils-cross_2014.07.bb
> > deleted file mode 100644
> > index d1f1f9a..000
> > --- a/meta/recipes-bsp/u-boot/u-boot-fw-utils-cross_2014.07.bb
> > +++ /dev/null
> > @@ -1,38 +0,0 @@
> > -SUMMARY = "U-Boot bootloader fw_printenv/setenv utilities"
> > -LICENSE = "GPLv2+"
> > -LIC_FILES_CHKSUM =
> > "file://Licenses/README;md5=025bf9f768cbcb1a165dbe1a110babfb"
> > -SECTION = "bootloader"
> > -DEPENDS = "mtd-utils"
> > -
> > -# This revision corresponds to the tag "v2014.07"
> > -# We use the revision in order to avoid having to fetch it from the
> > -# repo during parse
> > -SRCREV = "524123a70761110c5cf3ccc5f52f6d4da071b959"
> > -
> > -PV = "v2014.07+git${SRCPV}"
> > -
> > -SRC_URI = "git://git.denx.de/u-boot.git;branch=master;protocol=git"
> > -
> > -S = "${WORKDIR}/git"
> > -
> > -inherit uboot-config cross
> > -
> > -EXTRA_OEMAKE = 'CROSS_COMPILE=${TARGET_PREFIX} CC="${TARGET_PREFIX}gcc
> > ${TARGET_CC_ARCH} ${TOOLCHAIN_OPTIONS}"'
> > -
> > -do_compile () {
> > - oe_runmake ${UBOOT_MACHINE}
> > - oe_runmake env
> > -}
> > -
> > -do_install () {
> > - install -d ${D}${bindir_cross}
> > - install -m 755 ${S}/tools/env/fw_printenv
> > ${D}${bindir_cross}/fw_printenv
> > - install -m 755 ${S}/tools/env/fw_printenv ${D}${bindir_cross}/fw_setenv
> > -}
> > -
> > -SYSROOT_PREPROCESS_FUNCS = "uboot_fw_utils_cross"
> > -uboot_fw_utils_cross() {
> > - sysroot_stage_dir ${D}${bindir_cross} ${SYSROOT_DESTDIR}${bindir_cross}
> > -}
> > -
> > -PACKAGE_ARCH = "${MACHINE_ARCH}"
> > diff --git a/meta/recipes-bsp/u-boot/u-boot-fw-utils_2014.07.bb
> > b/meta/recipes-bsp/u-boot/u-boot-fw-utils_2014.07.bb
> > index a626c95..9a304c8 100644
> > --- a/meta/recipes-bsp/u-boot/u-boot-fw-utils_2014.07.bb
> > +++ b/meta/recipes-bsp/u-boot/u-boot-fw-utils_2014.07.bb
> > @@ -32,4 +32,16 @@ do_install () {
> > install -m 0644 ${S}/tools/env/fw_env.config
> > ${D}${sysconfdir}/fw_env.config
> > }
> >
> > +do_install_class-cross () {
> > +install -d ${D}${bindir_cross}
> > +install -m 755 ${S}/tools/env/fw_printenv
> > ${D}${bindir_cross}/fw_printenv
> > +install -m 755 ${S}/tools/env/fw_printenv ${D}${bindir_cross}/fw_setenv
> > +}
> > +
> > +SYSROOT_PREPROCESS_FUNCS_class-cross = "uboot_fw_utils_cross"
> > +uboot_fw_utils_cross() {
> > +sysroot_stage_dir ${D}${bindir_cross} ${SYSROOT_DESTDIR}${bindir_cross}
> > +}
> > +
> > PACKAGE_ARCH = "${MACHINE_ARCH}"
> > +BBCLASSEXTEND = "cross"
> > --
> > 2.1.4
> >
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [OE-Core][PATCH] gcc-sanitizers: fix licensing
On 23 January 2015 at 13:05, Dan McGregor wrote:
> From: Dan McGregor
>
> The sanitizer runtime library is dual-licensed under the NCSA
> and MIT licenses.
>
> Also make nativesdk-gcc-sanitizers use SDKGCCVERSION by default
> instead of GCCVERSION
>
> Signed-off-by: Dan McGregor
> ---
> meta/conf/distro/include/tcmode-default.inc | 2 +-
> meta/recipes-devtools/gcc/gcc-sanitizers.inc | 6 ++
> 2 files changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/meta/conf/distro/include/tcmode-default.inc
> b/meta/conf/distro/include/tcmode-default.inc
> index ae6aaf3..7428aa9 100644
> --- a/meta/conf/distro/include/tcmode-default.inc
> +++ b/meta/conf/distro/include/tcmode-default.inc
> @@ -39,7 +39,7 @@ PREFERRED_VERSION_gcc-runtime ?= "${GCCVERSION}"
> PREFERRED_VERSION_gcc-sanitizers ?= "${GCCVERSION}"
> PREFERRED_VERSION_gcc-source ?= "${GCCVERSION}"
> PREFERRED_VERSION_nativesdk-gcc-runtime ?= "${SDKGCCVERSION}"
> -PREFERRED_VERSION_nativesdk-gcc-sanitizers ?= "${GCCVERSION}"
> +PREFERRED_VERSION_nativesdk-gcc-sanitizers ?= "${SDKGCCVERSION}"
> PREFERRED_VERSION_libgcc ?= "${GCCVERSION}"
> PREFERRED_VERSION_libgcc-initial ?= "${GCCVERSION}"
> PREFERRED_VERSION_nativesdk-libgcc ?= "${SDKGCCVERSION}"
> diff --git a/meta/recipes-devtools/gcc/gcc-sanitizers.inc
> b/meta/recipes-devtools/gcc/gcc-sanitizers.inc
> index 892dfe0..35c9247 100644
> --- a/meta/recipes-devtools/gcc/gcc-sanitizers.inc
> +++ b/meta/recipes-devtools/gcc/gcc-sanitizers.inc
> @@ -1,5 +1,11 @@
> require gcc-configure-common.inc
>
> +LICENSE = "NCSA | MIT"
> +
> +LIC_FILES_CHKSUM = "\
> +file://libsanitizer/LICENSE.TXT;md5=0249c37748936faf5b1efd5789587909 \
> +"
> +
> EXTRA_OECONF_PATHS = "\
> --with-sysroot=/not/exist \
> --with-build-sysroot=${STAGING_DIR_TARGET} \
> --
> 2.1.0
Turns out I missed this the first time. Without this sanitizer runtime
is assumed to be GPL3 with runtime exception. It gets caught when one
blacklists GPL3 components.
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [OE-Core][PATCH] gcc-sanitizers: fix licensing
From: Dan McGregor
The sanitizer runtime library is dual-licensed under the NCSA
and MIT licenses.
Also make nativesdk-gcc-sanitizers use SDKGCCVERSION by default
instead of GCCVERSION
Signed-off-by: Dan McGregor
---
meta/conf/distro/include/tcmode-default.inc | 2 +-
meta/recipes-devtools/gcc/gcc-sanitizers.inc | 6 ++
2 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/meta/conf/distro/include/tcmode-default.inc
b/meta/conf/distro/include/tcmode-default.inc
index ae6aaf3..7428aa9 100644
--- a/meta/conf/distro/include/tcmode-default.inc
+++ b/meta/conf/distro/include/tcmode-default.inc
@@ -39,7 +39,7 @@ PREFERRED_VERSION_gcc-runtime ?= "${GCCVERSION}"
PREFERRED_VERSION_gcc-sanitizers ?= "${GCCVERSION}"
PREFERRED_VERSION_gcc-source ?= "${GCCVERSION}"
PREFERRED_VERSION_nativesdk-gcc-runtime ?= "${SDKGCCVERSION}"
-PREFERRED_VERSION_nativesdk-gcc-sanitizers ?= "${GCCVERSION}"
+PREFERRED_VERSION_nativesdk-gcc-sanitizers ?= "${SDKGCCVERSION}"
PREFERRED_VERSION_libgcc ?= "${GCCVERSION}"
PREFERRED_VERSION_libgcc-initial ?= "${GCCVERSION}"
PREFERRED_VERSION_nativesdk-libgcc ?= "${SDKGCCVERSION}"
diff --git a/meta/recipes-devtools/gcc/gcc-sanitizers.inc
b/meta/recipes-devtools/gcc/gcc-sanitizers.inc
index 892dfe0..35c9247 100644
--- a/meta/recipes-devtools/gcc/gcc-sanitizers.inc
+++ b/meta/recipes-devtools/gcc/gcc-sanitizers.inc
@@ -1,5 +1,11 @@
require gcc-configure-common.inc
+LICENSE = "NCSA | MIT"
+
+LIC_FILES_CHKSUM = "\
+file://libsanitizer/LICENSE.TXT;md5=0249c37748936faf5b1efd5789587909 \
+"
+
EXTRA_OECONF_PATHS = "\
--with-sysroot=/not/exist \
--with-build-sysroot=${STAGING_DIR_TARGET} \
--
2.1.0
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [RFC] About GPLv2's native recipe
On Friday 23 January 2015 09:04:28 akuster808 wrote: > On 01/23/2015 04:47 AM, Otavio Salvador wrote: > > On Fri, Jan 23, 2015 at 12:12 AM, Robert Yang wrote: > >> We have several GPLv2 recipes such as m4-native_1.4.9.bb, while we also > >> have GPLv3's m4-native_1.4.17.bb, I think that we can remove > >> m4-native_1.4.9.bb if the target m4_1.4.9.bb builds well ? > >> > >> I'd like to remove it because we don't build the lower native version by > >> default, and we don't know whether it works or when it would fail. > > > > I second this; not tested recipes are always good to remove. > > Speaking of not tested, what about 'BLACKLISTED' recipes? is there a > policy regarding how long to keep them around when they are in that state? We don't blacklist recipes in OE-Core, so you'd have to address that question to Martin or other layer maintainers who do do that. Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [RFC] About GPLv2's native recipe
On 01/23/2015 04:47 AM, Otavio Salvador wrote: On Fri, Jan 23, 2015 at 12:12 AM, Robert Yang wrote: We have several GPLv2 recipes such as m4-native_1.4.9.bb, while we also have GPLv3's m4-native_1.4.17.bb, I think that we can remove m4-native_1.4.9.bb if the target m4_1.4.9.bb builds well ? I'd like to remove it because we don't build the lower native version by default, and we don't know whether it works or when it would fail. I second this; not tested recipes are always good to remove. Speaking of not tested, what about 'BLACKLISTED' recipes? is there a policy regarding how long to keep them around when they are in that state? - Armin -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [RFC] About GPLv2's native recipe
On Fri, Jan 23, 2015 at 2:24 PM, Christopher Larson wrote: > > On Fri, Jan 23, 2015 at 5:47 AM, Otavio Salvador > wrote: >> >> On Fri, Jan 23, 2015 at 12:12 AM, Robert Yang >> wrote: >> > We have several GPLv2 recipes such as m4-native_1.4.9.bb, while we also >> > have GPLv3's m4-native_1.4.17.bb, I think that we can remove >> > m4-native_1.4.9.bb if the target m4_1.4.9.bb builds well ? >> > >> > I'd like to remove it because we don't build the lower native version by >> > default, and we don't know whether it works or when it would fail. >> >> I second this; not tested recipes are always good to remove. > > > The one case I'd be concerned with is where a native tool is used to > crosscompile something for the target, specifically in the case of scripting > tools which often have implicit dependency on the exact same version, so it > can parse what it needs to parse to build. Python for example, I doubt you'd > want to try to use 2.4 as part of the 2.7 crosscompilation process. m4 being > a scripting language, that might be the case here. Of course, if the > language is compatible between the two versions, maybe that's a non-issue. In this specific case, being m4 changed only minor versions it should be backward compatible. -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [RFC] About GPLv2's native recipe
On Fri, Jan 23, 2015 at 5:47 AM, Otavio Salvador wrote: > On Fri, Jan 23, 2015 at 12:12 AM, Robert Yang > wrote: > > We have several GPLv2 recipes such as m4-native_1.4.9.bb, while we also > > have GPLv3's m4-native_1.4.17.bb, I think that we can remove > > m4-native_1.4.9.bb if the target m4_1.4.9.bb builds well ? > > > > I'd like to remove it because we don't build the lower native version by > > default, and we don't know whether it works or when it would fail. > > I second this; not tested recipes are always good to remove. The one case I'd be concerned with is where a native tool is used to crosscompile something for the target, specifically in the case of scripting tools which often have implicit dependency on the exact same version, so it can parse what it needs to parse to build. Python for example, I doubt you'd want to try to use 2.4 as part of the 2.7 crosscompilation process. m4 being a scripting language, that might be the case here. Of course, if the language is compatible between the two versions, maybe that's a non-issue. -- Christopher Larson clarson at kergoth dot com Founder - BitBake, OpenEmbedded, OpenZaurus Maintainer - Tslib Senior Software Engineer, Mentor Graphics -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] qt4-x11-free: Fix Qt4 to build without opengl
Hi Fabien,
On Thursday 22 January 2015 15:08:35 Fabien Proriol wrote:
> ---
> meta/recipes-qt/qt4/qt4-x11-free.inc | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/meta/recipes-qt/qt4/qt4-x11-free.inc
> b/meta/recipes-qt/qt4/qt4-x11-free.inc index 3b1e0fe..d1b88ea 100644
> --- a/meta/recipes-qt/qt4/qt4-x11-free.inc
> +++ b/meta/recipes-qt/qt4/qt4-x11-free.inc
> @@ -4,7 +4,8 @@ SUMMARY = "Cross-platform UI toolkit and application
> framework (X11 version)" DESCRIPTION = "Qt is a versatile cross-platform
> application framework -- this is the X11 version." HOMEPAGE =
> "http://qt-project.org/";
> SECTION = "x11/libs"
> -DEPENDS += "virtual/libgl virtual/libx11 fontconfig libxft libxext
> libxrender libxrandr libxcursor" +DEPENDS += "virtual/libx11 fontconfig
> libxft libxext libxrender libxrandr libxcursor"
> +DEPENDS +=
> "${@bb.utils.contains('DISTRO_FEATURES', 'opengl', 'virtual/libgl', '', d)}
This is OK, but looking at how GL is configured in this file (via QT_GLFLAGS
which is set via ?= and thus could be overridden) I think maybe we should
check whether QT_CONFIG_FLAGS contains -opengl, i.e.:
DEPENDS += "${@bb.utils.contains('QT_CONFIG_FLAGS', '-opengl', 'virtual/libgl',
'', d)}"
(In other recipes we use PACKAGECONFIG to solve this kind of thing, but for
various reasons we aren't using PACKAGECONFIG in the Qt recipes apart from
qt-mobility).
Cheers,
Paul
--
Paul Eggleton
Intel Open Source Technology Centre
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] eglibc-use-option-groups.patch: Various fixups
On 22 January 2015 at 22:02, Peter Seebach wrote: > > ping. > > My memory (which is notoriously unreliable) was that we'd merged these > changes, but it may be we did thim in our local tree. > Yeah they're not in master - I think I merged and then backed them out locally to bisect some breakage. I'm testing here now. Ross -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [master][dizzy][PATCH 0/2] swig + pcre-config
The reason for the patch series is the observation that swig from meta-openembedded requires pcre-config to be installed on the host system, even though it does not actually get used. While that can be fixed in the swig recipe, investigating the situation led to the conclusion that the current handling of obsolete config scripts is sub-optimal and does not actually cause undesired usage of the patched scripts to fail. These two patches address that. They apply to master and dizzy. Applying also to dizzy would have the desirable effect of removing swig's host dependency without having to modify swig, but might also be a bit too intrusive for the stable series. Patrick Ohly (2): binconfig-disabled: try harder to prevent usage of config scripts binconfig-disabled: install config scripts in sysroot meta/classes/binconfig-disabled.bbclass | 13 + 1 file changed, 13 insertions(+) -- 1.8.4.5 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [master][dizzy][PATCH 2/2] binconfig-disabled: install config scripts in sysroot
The purpose of binconfig-disabled is to manipulate config scripts such that
using them causes errors. But that only works when the modified config script
really gets installed in the sysroot. That is not the case with the staging
code in binconfig.bbclass.
Only patched config files get staged. For that reason it seemed more
appropriate to change binconfig-disabled instead of binconfig.
The reason for the change was the observation that the swig recipe needs
pcre-config installed on the host system. Staging pcre-config removes that
host dependency. swig did not actually end up *using* the pcre-config from the
host, because later during do_compile the patched configure.ac is used to
re-generate configure.
Signed-off-by: Patrick Ohly
---
meta/classes/binconfig-disabled.bbclass | 10 ++
1 file changed, 10 insertions(+)
diff --git a/meta/classes/binconfig-disabled.bbclass
b/meta/classes/binconfig-disabled.bbclass
index 4c42ae2..0acc964 100644
--- a/meta/classes/binconfig-disabled.bbclass
+++ b/meta/classes/binconfig-disabled.bbclass
@@ -16,3 +16,13 @@ do_install_append () {
echo "exit 1" >> ${D}$x
done
}
+
+SYSROOT_PREPROCESS_FUNCS += "binconfig_disabled_sysroot_preprocess"
+
+binconfig_disabled_sysroot_preprocess () {
+ for x in ${BINCONFIG}; do
+ configname=`basename $x`
+ install -d ${SYSROOT_DESTDIR}${bindir_crossscripts}
+ install ${D}$x ${SYSROOT_DESTDIR}${bindir_crossscripts}
+ done
+}
--
1.8.4.5
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [master][dizzy][PATCH 1/2] binconfig-disabled: try harder to prevent usage of config scripts
Returning a non-zero exit code is not enough to cause errors when configure
scripts call the patched config scripts: for example, swig's configure script
uses PCRE_LIBS=`$PCRE_CONFIG --libs` and does not abort on errors. Using empty
output may then succeed, for example when the required library is available
indirectly.
Returning some nonsense command line arguments covers such cases, because
using them will definitely lead to errors during compilation. The faked
arguments were chosen such that these errors can be linked back to the root
cause.
Signed-off-by: Patrick Ohly
---
meta/classes/binconfig-disabled.bbclass | 3 +++
1 file changed, 3 insertions(+)
diff --git a/meta/classes/binconfig-disabled.bbclass
b/meta/classes/binconfig-disabled.bbclass
index 27f904e..4c42ae2 100644
--- a/meta/classes/binconfig-disabled.bbclass
+++ b/meta/classes/binconfig-disabled.bbclass
@@ -10,6 +10,9 @@ FILES_${PN}-dev += "${bindir}/*-config"
do_install_append () {
for x in ${BINCONFIG}; do
echo "#!/bin/sh" > ${D}$x
+ # Make the disabled script emit invalid parameters for those
configure
+ # scripts which call it without checking the return code.
+ echo "echo '--should-not-have-used-$x'" > ${D}$x
echo "exit 1" >> ${D}$x
done
}
--
1.8.4.5
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [RFC] About GPLv2's native recipe
On Fri, Jan 23, 2015 at 12:12 AM, Robert Yang wrote: > We have several GPLv2 recipes such as m4-native_1.4.9.bb, while we also > have GPLv3's m4-native_1.4.17.bb, I think that we can remove > m4-native_1.4.9.bb if the target m4_1.4.9.bb builds well ? > > I'd like to remove it because we don't build the lower native version by > default, and we don't know whether it works or when it would fail. I second this; not tested recipes are always good to remove. -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCHv2 3/4] xorg-driver: add x11 to required DISTRO_FEATURES
On 22 January 2015 at 16:34, Martin Jansa wrote: > and the .inc file is used in much more recipes (which don't need libx11 to > build) > You can't be arguing that it's alright to build the X11 drivers when the X11 distro feature is disabled? I thought the end goal was to cover all X11 recipes, not just the ones that happen to link to libx11? Ross -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/1] pseudo_1.6.x.bb/pseudo_git.bb: Pseudo 1.6.4
On 23 January 2015 at 02:23, Peter Seebach wrote: > pseudo 1.6.4 fixes a silly configure bug introduced with > 1.6.3. > Thanks for the quick fix Peter :) Ross -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/1] Add XFCE image build bb file
Thanks Ross, I will send this patch to meta-xfce later 2015-01-23 18:48 GMT+08:00 Burton, Ross : > > On 23 January 2015 at 07:55, Yong Li wrote: > >> meta/recipes-graphics/images/core-image-xfce.bb | 16 >> > > This doesn't belong in oe-core, add it to meta-xfce instead. > > Ross > -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/1] Add XFCE image build bb file
On 23 January 2015 at 07:55, Yong Li wrote: > meta/recipes-graphics/images/core-image-xfce.bb | 16 > This doesn't belong in oe-core, add it to meta-xfce instead. Ross -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
