[OE-core] [PATCH] cross-canadian.bbclass: Do not override LIBCOVERRIDE with SDK libc override
cross-canadian tools are supposed to generate code for target and if we
override the libc override then needed overrides do not get applied when
building gcc cross canadian e.g. for baremetal, which causes build
failures during compile
e.g. https://github.com/riscv/meta-riscv/issues/117
Not override libc override helps us fix this issue
Signed-off-by: Khem Raj
---
meta/classes/cross-canadian.bbclass | 1 -
1 file changed, 1 deletion(-)
diff --git a/meta/classes/cross-canadian.bbclass
b/meta/classes/cross-canadian.bbclass
index f5c9f61595..ee53faad79 100644
--- a/meta/classes/cross-canadian.bbclass
+++ b/meta/classes/cross-canadian.bbclass
@@ -9,7 +9,6 @@
# or indirectly via dependency. No need to be in 'world'.
EXCLUDE_FROM_WORLD = "1"
NATIVESDKLIBC ?= "libc-glibc"
-LIBCOVERRIDE = ":${NATIVESDKLIBC}"
CLASSOVERRIDE = "class-cross-canadian"
STAGING_BINDIR_TOOLCHAIN =
"${STAGING_DIR_NATIVE}${bindir_native}/${SDK_ARCH}${SDK_VENDOR}-${SDK_OS}:${STAGING_DIR_NATIVE}${bindir_native}/${TARGET_ARCH}${TARGET_VENDOR}-${TARGET_OS}"
--
2.21.0
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 2/2] goarch.bbclass: set TARGET_GOARM as '7' for cortexa7
On Wed, Mar 13, 2019 at 1:04 PM Mark Asselstine
wrote:
>
> On Wednesday, March 13, 2019 3:56:10 PM EDT Andre McCurdy wrote:
> > On Wed, Mar 13, 2019 at 10:57 AM Mark Asselstine
> >
> > wrote:
> > > The cortexa7 tunings use 'cortexa7' in their tunings and do not
> > > include 'arm7' so we need to look for both when setting TARGET_GOARM.
> >
> > Is cortexa7 a special case? Or will the same issue be there for
> > cortexa5, cortexa9, cortexa15, etc?
>
> Damn, was too fucused on the 1/2 patch of this RR I had my blinders on. Yes I
> should be looking for cortexa* as I believe they all fall in to the "7"
keep in mind we might have cortex-a53 etc which are v8
> bucket. I will redo this and after we sort out 1/2 I will send a v2.
>
> MarkA
>
> >
> > > Signed-off-by: Mark Asselstine
> > > ---
> > >
> > > meta/classes/goarch.bbclass | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/meta/classes/goarch.bbclass b/meta/classes/goarch.bbclass
> > > index 39fea5e..077c967 100644
> > > --- a/meta/classes/goarch.bbclass
> > > +++ b/meta/classes/goarch.bbclass
> > >
> > > @@ -74,7 +74,7 @@ def go_map_arch(a, d):
> > > def go_map_arm(a, f, d):
> > > import re
> > >
> > > if re.match('arm.*', a):
> > > -if 'armv7' in f:
> > >
> > > +if 'armv7' or 'cortexa7' in f:
> > > return '7'
> > >
> > > elif 'armv6' in f:
> > > return '6'
> > >
> > > --
> > > 2.7.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
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [oe-core][PATCH 1/1] puzzles: fix uninitialized variable compiler error
On Thu, Mar 14, 2019 at 12:20 PM Joe Slater wrote:
>
> In tree234.c, change a while() loop to a for() loop so
> that the compiler will realize we loop at least once.
>
> Signed-off-by: Joe Slater
> ---
> .../puzzles/files/fix-ki-uninitialized.patch | 25
> ++
> meta/recipes-sato/puzzles/puzzles_git.bb | 1 +
> 2 files changed, 26 insertions(+)
> create mode 100644 meta/recipes-sato/puzzles/files/fix-ki-uninitialized.patch
>
> diff --git a/meta/recipes-sato/puzzles/files/fix-ki-uninitialized.patch
> b/meta/recipes-sato/puzzles/files/fix-ki-uninitialized.patch
> new file mode 100644
> index 000..7218d62
> --- /dev/null
> +++ b/meta/recipes-sato/puzzles/files/fix-ki-uninitialized.patch
> @@ -0,0 +1,25 @@
> +puzzles: avoid compiler unitialized variable error
> +
> +The compiler does not realize that we must go through the while()
> +loop at least once, so we replace it with a for() loop.
> +
> +Upstream-Status: Pending
> +
> +Signed-off-by: Joe Slater
> +
> +--- a/tree234.c
> b/tree234.c
> +@@ -326,8 +326,11 @@ static void *add234_internal(tree234 *t,
> + return orig_e;
> + }
> +
> +-n = t->root;
> +-while (n) {
> ++/*
> ++ * We know t->root is not NULL. The logic
> ++ * to break out of this is at the end of the loop.
> ++ */
> ++for (n = t->root;;) {
may do .. while () is better
> + LOG((" node %p: %p/%d \"%s\" %p/%d \"%s\" %p/%d \"%s\" %p/%d\n",
> +n,
> +n->kids[0], n->counts[0], n->elems[0],
> diff --git a/meta/recipes-sato/puzzles/puzzles_git.bb
> b/meta/recipes-sato/puzzles/puzzles_git.bb
> index 0766bd4..59b9525 100644
> --- a/meta/recipes-sato/puzzles/puzzles_git.bb
> +++ b/meta/recipes-sato/puzzles/puzzles_git.bb
> @@ -14,6 +14,7 @@ SRC_URI = "git://git.tartarus.org/simon/puzzles.git \
> file://0001-palisade-Fix-warnings-with-clang-on-arm.patch \
>
> file://0001-Use-Wno-error-format-overflow-if-the-compiler-suppor.patch \
>
> file://0001-pattern.c-Change-string-lenght-parameter-to-be-size_.patch \
> + file://fix-ki-uninitialized.patch \
> "
>
> UPSTREAM_CHECK_COMMITS = "1"
> --
> 2.7.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] [PATCHv4 1/2] Revert "arm-tunes: Remove -march option if mcpu is already added"
I have sent an alternative, please see if that works for you. I think
that could be simpler
On Thu, Mar 14, 2019 at 8:04 AM Peter Kjellerstedt
wrote:
>
> This reverts commit ac83d22eb5031f7fdd09d34a1a46d92fd3e39a3c.
>
> This solution had unforeseen side effects, which, e.g., lead to the
> following sanity error if trying to build with the arm926ejs default
> tune:
>
> Error, the PACKAGE_ARCHS variable (all any noarch arm armv4 armv4t
> armv5 armv5t armv5e armv5te arm926ejste arm926ejse withheld>) for DEFAULTTUNE (arm926ejs) does not contain
> TUNE_PKGARCH (arm926ejst).
>
> An alternative solution will follow, which only affects the -mcpu and
> -march options without other side effects.
>
> Signed-off-by: Peter Kjellerstedt
> ---
> meta/conf/machine/include/tune-arm1136jf-s.inc | 4 +---
> meta/conf/machine/include/tune-arm920t.inc | 4 +---
> meta/conf/machine/include/tune-arm926ejs.inc | 4 +---
> meta/conf/machine/include/tune-arm9tdmi.inc | 4 +---
> meta/conf/machine/include/tune-cortexa15.inc | 27 ++-
> meta/conf/machine/include/tune-cortexa17.inc | 27 ++-
> meta/conf/machine/include/tune-cortexa5.inc | 27 ++-
> meta/conf/machine/include/tune-cortexa7.inc | 27 ++-
> meta/conf/machine/include/tune-cortexa8.inc | 19 +++-
> meta/conf/machine/include/tune-cortexa9.inc | 28
> ++--
> meta/conf/machine/include/tune-ep9312.inc| 1 -
> meta/conf/machine/include/tune-iwmmxt.inc| 3 +--
> meta/conf/machine/include/tune-strongarm1100.inc | 3 +--
> meta/conf/machine/include/tune-xscale.inc| 7 ++
> 14 files changed, 76 insertions(+), 109 deletions(-)
>
> diff --git a/meta/conf/machine/include/tune-arm1136jf-s.inc
> b/meta/conf/machine/include/tune-arm1136jf-s.inc
> index d883eba7c9..c5de63e1cc 100644
> --- a/meta/conf/machine/include/tune-arm1136jf-s.inc
> +++ b/meta/conf/machine/include/tune-arm1136jf-s.inc
> @@ -4,10 +4,8 @@ require conf/machine/include/arm/arch-armv6.inc
>
> TUNEVALID[arm1136jfs] = "Enable arm1136jfs specific processor optimizations"
> TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'arm1136jfs', '
> -mcpu=arm1136jf-s', '', d)}"
> -MACHINEOVERRIDES =. "${@bb.utils.contains('TUNE_FEATURES', 'arm1136jfs',
> 'armv6:', '' ,d)}"
>
> AVAILTUNES += "arm1136jfs"
> ARMPKGARCH_tune-arm1136jfs = "arm1136jfs"
> -# mcpu is used so don't use armv6 as we don't want march
> -TUNE_FEATURES_tune-arm1136jfs = "arm arm1136jfs"
> +TUNE_FEATURES_tune-arm1136jfs = "${TUNE_FEATURES_tune-armv6} arm1136jfs"
> PACKAGE_EXTRA_ARCHS_tune-arm1136jfs = "${PACKAGE_EXTRA_ARCHS_tune-armv6}
> arm1136jfs-vfp"
> diff --git a/meta/conf/machine/include/tune-arm920t.inc
> b/meta/conf/machine/include/tune-arm920t.inc
> index 42e8ed2b51..c6e74b6772 100644
> --- a/meta/conf/machine/include/tune-arm920t.inc
> +++ b/meta/conf/machine/include/tune-arm920t.inc
> @@ -4,10 +4,8 @@ require conf/machine/include/arm/arch-armv4.inc
>
> TUNEVALID[arm920t] = "Enable arm920t specific processor optimizations"
> TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'arm920t', '
> -mcpu=arm920t', '', d)}"
> -MACHINEOVERRIDES =. "${@bb.utils.contains('TUNE_FEATURES', 'arm920t',
> 'armv4:', '' ,d)}"
>
> AVAILTUNES += "arm920t"
> ARMPKGARCH_tune-arm920t = "arm920t"
> -# mcpu is used so don't use armv4t as we don't want march
> -TUNE_FEATURES_tune-arm920t = "arm thumb arm920t"
> +TUNE_FEATURES_tune-arm920t = "${TUNE_FEATURES_tune-armv4t} arm920t"
> PACKAGE_EXTRA_ARCHS_tune-arm920t = "${PACKAGE_EXTRA_ARCHS_tune-armv4t}
> arm920t arm920tt"
> diff --git a/meta/conf/machine/include/tune-arm926ejs.inc
> b/meta/conf/machine/include/tune-arm926ejs.inc
> index 563d53bc4e..81bcda339b 100644
> --- a/meta/conf/machine/include/tune-arm926ejs.inc
> +++ b/meta/conf/machine/include/tune-arm926ejs.inc
> @@ -4,10 +4,8 @@ require conf/machine/include/arm/arch-armv5-dsp.inc
>
> TUNEVALID[arm926ejs] = "Enable arm926ejs specific processor optimizations"
> TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'arm926ejs', '
> -mcpu=arm926ej-s', '', d)}"
> -MACHINEOVERRIDES =. "${@bb.utils.contains('TUNE_FEATURES', 'arm926ejs',
> 'armv5:', '' ,d)}"
>
> AVAILTUNES += "arm926ejs"
> ARMPKGARCH_tune-arm926ejs = "arm926ejs"
> -# mcpu is used so don't use armv5te as we don't want march
> -TUNE_FEATURES_tune-arm926ejs = "arm thumb dsp arm926ejs"
> +TUNE_FEATURES_tune-arm926ejs = "${TUNE_FEATURES_tune-armv5te} arm926ejs"
> PACKAGE_EXTRA_ARCHS_tune-arm926ejs = "${PACKAGE_EXTRA_ARCHS_tune-armv5te}
> arm926ejste arm926ejse"
> diff --git a/meta/conf/machine/include/tune-arm9tdmi.inc
> b/meta/conf/machine/include/tune-arm9tdmi.inc
> index e03a8b86a0..e9c2b8fcf5 100644
> --- a/meta/conf/machine/include/tune-arm9tdmi.inc
> +++ b/meta/conf/machine/include/tune-arm9tdmi.inc
> @@ -4,10 +4,8 @@ require conf/machine/include/arm/arch-armv4.inc
>
>
Re: [OE-core] Can't build product that uses DEFAULTTUNE="arm926ejs"
On Mon, Mar 11, 2019 at 6:49 AM Peter Kjellerstedt
wrote:
>
> > -Original Message-
> > From: Khem Raj
> > Sent: den 11 mars 2019 05:24
> > To: Peter Kjellerstedt
> > Cc: OE Core (openembedded-core@lists.openembedded.org) > c...@lists.openembedded.org>
> > Subject: Re: Can't build product that uses DEFAULTTUNE="arm926ejs"
> >
> > On Sun, Mar 10, 2019 at 9:20 PM Peter Kjellerstedt
> > wrote:
> > >
> > > I'm trying to build with master of OE-core and one of our products
> > > now fails with:
> > >
> > > ERROR: OE-core's config sanity checker detected a potential
> > > misconfiguration.
> > > Either fix the cause of this error or at your own risk disable the
> > > checker
> > > (see sanity.conf). Following is the list of potential problems /
> > > advisories:
> > >
> > > Error, the PACKAGE_ARCHS variable (all any noarch arm armv4 armv4t
> > > armv5
> > > armv5t armv5e armv5te arm926ejste arm926ejse ) for
> > > DEFAULTTUNE (arm926ejs) does not contain TUNE_PKGARCH (arm926ejst).
> > >
> > > I believe this is due to commit ac83d22e (arm-tunes: Remove -march
> > > option if mcpu is already added). If I build with Thud, TUNE_PKGARCH
> > > is "arm926ejste". The lack of the "e" at the end when building with
> > > master seems to be due to the definition of ARMPKGSFX_DSP as
> > > "${@bb.utils.contains('TUNE_FEATURES', [ 'armv5', 'dsp' ], 'e', '', d)}"
> > > and the fact that after commit ac83d22e, TUNE_FEATURES no longer
> > > contains 'armv5'.
> >
> > right this should now check for armv5t
>
> There is no armv5t to check for.
>
> > armv5 has been removed from upstream gcc as well. So we only support
> > armv5t variants.
> >
> > > //Peter
>
> I am by no means any expert on the tuning files (actually they mostly
> seem like black magic), but I devised an alternative solution for
> preferring -mcpu over -march that I think is less invasive and without
> unwanted side effects. I will publish it shortly.
I saw you sent couple of patch to address this, however I think it can
be addressed a bit differently and patch could
be simple. I would be keen if you try it out and see if that fixes your problem
https://patchwork.openembedded.org/patch/159591/
>
> //Peter
>
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] arch-armv5-dsp.inc: Check for dsp only to enable 'e' in package arches
armv5 is not a specific tune feature anymore, there is no need to check
it, since having dsp will define if 'e' should be added or not
Signed-off-by: Khem Raj
Cc: Peter Kjellerstedt
---
meta/conf/machine/include/arm/arch-armv5-dsp.inc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/conf/machine/include/arm/arch-armv5-dsp.inc
b/meta/conf/machine/include/arm/arch-armv5-dsp.inc
index 1f16085fcd..d117af1520 100644
--- a/meta/conf/machine/include/arm/arch-armv5-dsp.inc
+++ b/meta/conf/machine/include/arm/arch-armv5-dsp.inc
@@ -1,4 +1,4 @@
-ARMPKGSFX_DSP = "${@bb.utils.contains('TUNE_FEATURES', [ 'armv5', 'dsp' ],
'e', '', d)}"
+ARMPKGSFX_DSP = "${@bb.utils.contains('TUNE_FEATURES', [ 'dsp' ], 'e', '', d)}"
TUNEVALID[dsp] = "ARM DSP functionality"
require conf/machine/include/arm/arch-armv5.inc
--
2.21.0
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [v2][PATCH 1/2] go.bbclass: Export GOARM
On Thu, Mar 14, 2019 at 1:05 PM Mark Asselstine
wrote:
>
> When building GO packages for ARM (v5, v6, v7) it is expected that the
> GOARM env variable is set during the build. Not having GOARM exported
> will result in GO binaries which can't be executed on the target
> (terminate with segfault). Per https://github.com/golang/go/wiki/GoArm
>
> We already have the logic in goarch.bbclass to determine the correct
> value of GOARM (see GOARM_TARGET), but currently this is only used to
> build go itself (go-cross_1.*.bb requires go-cross.inc --> export
> GOARM = "${TARGET_GOARM}").
>
> Here we export GOARM but we do it such that it is only exported if we
> are building for 'arm' and only when recipes requiring/inheriting
> go.bbclass are be used to build for the target.
>
> Signed-off-by: Mark Asselstine
> ---
>
> V2
> * Avoid potential undefined situations
>
> meta/classes/go.bbclass | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/meta/classes/go.bbclass b/meta/classes/go.bbclass
> index af331f8..5af4c3e 100644
> --- a/meta/classes/go.bbclass
> +++ b/meta/classes/go.bbclass
> @@ -8,6 +8,10 @@ GOROOT = "${STAGING_LIBDIR}/go"
> export GOROOT
> export GOROOT_FINAL = "${libdir}/go"
>
> +GOARM[export] = "0"
> +GOARM_arm_class-target = "${TARGET_GOARM}"
> +GOARM_arm_class-target[export] = "1"
> +
while this works, I think it would be nicer to handle it for all
export GOHOSTOS = "${BUILD_GOOS}"
export GOHOSTARCH = "${BUILD_GOARCH}"
export GOOS = "${TARGET_GOOS}"
export GOARCH = "${TARGET_GOARCH}"
export GOARM = "${TARGET_GOARM}"
export GO386 = "${TARGET_GO386}"
export GOMIPS = "${TARGET_GOMIPS}"
these should all be replicated into bbclass.
> DEPENDS_GOLANG_class-target = "virtual/${TUNE_PKGARCH}-go
> virtual/${TARGET_PREFIX}go-runtime"
> DEPENDS_GOLANG_class-native = "go-native"
> DEPENDS_GOLANG_class-nativesdk = "virtual/${TARGET_PREFIX}go-crosssdk
> virtual/${TARGET_PREFIX}go-runtime"
> --
> 2.7.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] [v2][PATCH 2/2] goarch.bbclass: set TARGET_GOARM as '7' for valid cortexa* targets
On Thu, Mar 14, 2019 at 1:05 PM Mark Asselstine
wrote:
>
> Per https://github.com/golang/go/wiki/GoArm we need to set GOARM when
> building for ARMv5, ARMv6 and ARMv7. The current code in go_map_arm()
> does not account for the Cortex* TUNINGs and as such misses several
> Cortex variants which implement ARMv7. Here we add an additional check
> that will include Cortex-A5 through Cortex-A17 as ARMv7 variants
> (ie. GOARM='7'). The Cortex-R and Cortex-M variants are also captured
> even though there are no tunings for these currently (lack MMU support
> so not supported).
>
> Signed-off-by: Mark Asselstine
> ---
>
> V2
> * Cover all ARMv7 Cortex* variants
Still worried this might not be complete. It's basically fixing the
fallout from Khem's patches to remove -march options from the CPU
specific ARM machine includes, right? If so then any ARM machine with
CPU specific tuning (other than cortex) is still going to be affected.
What's the reason for parsing TUNE_FEATURES to detect the ARM
architecture level? Couldn't GOARM be set correctly just by using of
the _armv5, _armv6, _armv7a and _armv7ve over-rides?
https://github.com/golang/go/wiki/GoArm
> meta/classes/goarch.bbclass | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/meta/classes/goarch.bbclass b/meta/classes/goarch.bbclass
> index 39fea5e..84977a5 100644
> --- a/meta/classes/goarch.bbclass
> +++ b/meta/classes/goarch.bbclass
> @@ -74,6 +74,10 @@ def go_map_arch(a, d):
> def go_map_arm(a, f, d):
> import re
> if re.match('arm.*', a):
> +for el in f.split():
> +m = re.match("cortex[arm](\d.*)", el)
> +if m and int(m.group(1)) < 32:
> + return '7'
> if 'armv7' in f:
> return '7'
> elif 'armv6' in f:
> --
> 2.7.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][Thud][PATCH 1/3] lttng-ust: update to 2.10.3
On 3/14/19 9:29 AM, Jonathan Rajotte-Julien wrote: >>> Disregard this series. It does not follow the project guideline regarding >>> recipe >>> update for stable release. >> There are exceptions when a package update is a bugfix only change. I >> know the kernel, openssl, bind, curl and a few others fall into that >> category. Many minor version updates tend to be bug fix only but that >> all depends on the upstream project policies. Binutils does not follow >> that scheme as they add features in minor version updates. This is what >> I know from personal experience. What helps the project along with the >> maintainer is having a brief summary of the changes in the commit >> message. I am at the mercy of commit message. > I get that. I assumed that most project are *sane* and stick to something > similar to SemVer. Sorry for that. > > We follow SemVer [1] for the following projects: > > Babeltrace > LTTng-tools > LTTng-ust > LTTng-modules > userspace-rcu > > This series contains only PATCH level update (MAJOR.MINOR.PATCH). > > You will note that the lttng-tools recipes was not updated to the 2.10.x > release > in this series. > > Side note, as a project (lttng) we recommend that lttng-tools and lttng-ust be > upgraded in lockstep (MINOR == MINOR). But since we also conform to SemVer > there > is no problem using an older MINOR version of lttng-tools with a newer MINOR > version of lttng-ust. The other way around is not recommended and will simply > not build most of the time. > > lttng-modules is *special* since we fix thing to allow support of > newer kernel as time goes by. Again, we do not add features across PATCH level > release. > > Still, I think I understand a bit more the constraint oe-core and yocto stable > branch are facing and would not mind if the recipes stay at the version they > are > now. > > [1] https://semver.org/ Thank you for the explanation. This will help me moving forward. > >> Can you confirm this is bug fix only update? >> > Yes it is. Great. I took your series and have them in the builds. regards, Armin > > Cheers > -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] libnss-nisplus: Add recipe
On Thu, Mar 14, 2019 at 12:43 PM Ruslan Bilovol wrote:
> Same as with libnss-nis - this will substitute
> the glibc nisplus module which has been removed
>
> SRCREV points to 1.3 release plus patch on top which
> allows to build with recent glibc versions
This looks okay but not
An Oe core candidate to me
>
>
> Signed-off-by: Ruslan Bilovol
> ---
> .../libnss-nisplus/libnss-nisplus.bb | 31
> ++
> 1 file changed, 31 insertions(+)
> create mode 100644 meta/recipes-extended/libnss-nisplus/libnss-nisplus.bb
>
> diff --git a/meta/recipes-extended/libnss-nisplus/libnss-nisplus.bb
> b/meta/recipes-extended/libnss-nisplus/libnss-nisplus.bb
> new file mode 100644
> index 000..2dbeee7
> --- /dev/null
> +++ b/meta/recipes-extended/libnss-nisplus/libnss-nisplus.bb
> @@ -0,0 +1,31 @@
> +# Copyright (C) 2019 Ruslan Bilovol
> +# Released under the MIT license (see COPYING.MIT for the terms)
> +
> +SUMMARY = "NSS module for glibc, to provide NIS+ support for glibc"
> +
> +DESCRIPTION = "This package contains the NSS NIS+ plugin for glibc.\
> +This code was formerly part of glibc, but is now standalone to\
> +be able to link against TI-RPC for IPv6 support."
> +
> +HOMEPAGE = "https://github.com/thkukuk/libnss_nisplus";
> +LICENSE = "LGPL-2.1"
> +LIC_FILES_CHKSUM = "file://COPYING;md5=4fbd65380cdd255951079008b364516c"
> +SECTION = "libs"
> +DEPENDS += "libtirpc libnsl2"
> +
> +PV = "1.3+git${SRCPV}"
> +
> +SRCREV = "c6934373c7bac91499ff7bbe7d2439599325ca63"
> +
> +SRC_URI = "git://github.com/thkukuk/libnss_nisplus \
> + "
> +
> +S = "${WORKDIR}/git"
> +
> +inherit autotools pkgconfig
> +
> +BBCLASSEXTEND += "native nativesdk"
> +#
> +# We will skip parsing this packagegeoup for non-glibc systems
> +#
> +COMPATIBLE_HOST_libc-musl = 'null'
> --
> 1.9.1
>
>
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] openssl: fix CVE-2019-1543
Signed-off-by: Ross Burton
---
.../openssl/openssl/CVE-2019-1543.patch| 69 ++
.../recipes-connectivity/openssl/openssl_1.1.1a.bb | 1 +
2 files changed, 70 insertions(+)
create mode 100644
meta/recipes-connectivity/openssl/openssl/CVE-2019-1543.patch
diff --git a/meta/recipes-connectivity/openssl/openssl/CVE-2019-1543.patch
b/meta/recipes-connectivity/openssl/openssl/CVE-2019-1543.patch
new file mode 100644
index 000..59a92f06e42
--- /dev/null
+++ b/meta/recipes-connectivity/openssl/openssl/CVE-2019-1543.patch
@@ -0,0 +1,69 @@
+Upstream-Status: Backport
[https://github.com/openssl/openssl/commit/f426625b6ae9a7831010750490a5f0ad689c5ba3]
+Signed-off-by: Ross Burton
+
+From f426625b6ae9a7831010750490a5f0ad689c5ba3 Mon Sep 17 00:00:00 2001
+From: Matt Caswell
+Date: Tue, 5 Mar 2019 14:39:15 +
+Subject: [PATCH] Prevent over long nonces in ChaCha20-Poly1305
+
+ChaCha20-Poly1305 is an AEAD cipher, and requires a unique nonce input for
+every encryption operation. RFC 7539 specifies that the nonce value (IV)
+should be 96 bits (12 bytes). OpenSSL allows a variable nonce length and
+front pads the nonce with 0 bytes if it is less than 12 bytes. However it
+also incorrectly allows a nonce to be set of up to 16 bytes. In this case
+only the last 12 bytes are significant and any additional leading bytes are
+ignored.
+
+It is a requirement of using this cipher that nonce values are unique.
+Messages encrypted using a reused nonce value are susceptible to serious
+confidentiality and integrity attacks. If an application changes the
+default nonce length to be longer than 12 bytes and then makes a change to
+the leading bytes of the nonce expecting the new value to be a new unique
+nonce then such an application could inadvertently encrypt messages with a
+reused nonce.
+
+Additionally the ignored bytes in a long nonce are not covered by the
+integrity guarantee of this cipher. Any application that relies on the
+integrity of these ignored leading bytes of a long nonce may be further
+affected.
+
+Any OpenSSL internal use of this cipher, including in SSL/TLS, is safe
+because no such use sets such a long nonce value. However user
+applications that use this cipher directly and set a non-default nonce
+length to be longer than 12 bytes may be vulnerable.
+
+CVE-2019-1543
+
+Fixes #8345
+
+Reviewed-by: Paul Dale
+Reviewed-by: Richard Levitte
+(Merged from https://github.com/openssl/openssl/pull/8406)
+
+(cherry picked from commit 2a3d0ee9d59156c48973592331404471aca886d6)
+---
+ crypto/evp/e_chacha20_poly1305.c | 4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+diff --git a/crypto/evp/e_chacha20_poly1305.c
b/crypto/evp/e_chacha20_poly1305.c
+index c1917bb86a6..d3e2c622a1b 100644
+--- a/crypto/evp/e_chacha20_poly1305.c
b/crypto/evp/e_chacha20_poly1305.c
+@@ -30,6 +30,8 @@ typedef struct {
+
+ #define data(ctx) ((EVP_CHACHA_KEY *)(ctx)->cipher_data)
+
++#define CHACHA20_POLY1305_MAX_IVLEN 12
++
+ static int chacha_init_key(EVP_CIPHER_CTX *ctx,
+const unsigned char user_key[CHACHA_KEY_SIZE],
+const unsigned char iv[CHACHA_CTR_SIZE], int enc)
+@@ -533,7 +535,7 @@ static int chacha20_poly1305_ctrl(EVP_CIPHER_CTX *ctx, int
type, int arg,
+ return 1;
+
+ case EVP_CTRL_AEAD_SET_IVLEN:
+-if (arg <= 0 || arg > CHACHA_CTR_SIZE)
++if (arg <= 0 || arg > CHACHA20_POLY1305_MAX_IVLEN)
+ return 0;
+ actx->nonce_len = arg;
+ return 1;
diff --git a/meta/recipes-connectivity/openssl/openssl_1.1.1a.bb
b/meta/recipes-connectivity/openssl/openssl_1.1.1a.bb
index 30e0e7a19a0..0046c25554c 100644
--- a/meta/recipes-connectivity/openssl/openssl_1.1.1a.bb
+++ b/meta/recipes-connectivity/openssl/openssl_1.1.1a.bb
@@ -17,6 +17,7 @@ SRC_URI = "http://www.openssl.org/source/openssl-${PV}.tar.gz
\
file://0001-skip-test_symbol_presence.patch \
file://0001-buildinfo-strip-sysroot-and-debug-prefix-map-from-co.patch \
file://afalg.patch \
+ file://CVE-2019-1543.patch \
"
SRC_URI_append_class-nativesdk = " \
--
2.11.0
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [v2][PATCH 1/2] go.bbclass: Export GOARM
When building GO packages for ARM (v5, v6, v7) it is expected that the
GOARM env variable is set during the build. Not having GOARM exported
will result in GO binaries which can't be executed on the target
(terminate with segfault). Per https://github.com/golang/go/wiki/GoArm
We already have the logic in goarch.bbclass to determine the correct
value of GOARM (see GOARM_TARGET), but currently this is only used to
build go itself (go-cross_1.*.bb requires go-cross.inc --> export
GOARM = "${TARGET_GOARM}").
Here we export GOARM but we do it such that it is only exported if we
are building for 'arm' and only when recipes requiring/inheriting
go.bbclass are be used to build for the target.
Signed-off-by: Mark Asselstine
---
V2
* Avoid potential undefined situations
meta/classes/go.bbclass | 4
1 file changed, 4 insertions(+)
diff --git a/meta/classes/go.bbclass b/meta/classes/go.bbclass
index af331f8..5af4c3e 100644
--- a/meta/classes/go.bbclass
+++ b/meta/classes/go.bbclass
@@ -8,6 +8,10 @@ GOROOT = "${STAGING_LIBDIR}/go"
export GOROOT
export GOROOT_FINAL = "${libdir}/go"
+GOARM[export] = "0"
+GOARM_arm_class-target = "${TARGET_GOARM}"
+GOARM_arm_class-target[export] = "1"
+
DEPENDS_GOLANG_class-target = "virtual/${TUNE_PKGARCH}-go
virtual/${TARGET_PREFIX}go-runtime"
DEPENDS_GOLANG_class-native = "go-native"
DEPENDS_GOLANG_class-nativesdk = "virtual/${TARGET_PREFIX}go-crosssdk
virtual/${TARGET_PREFIX}go-runtime"
--
2.7.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [v2][PATCH 2/2] goarch.bbclass: set TARGET_GOARM as '7' for valid cortexa* targets
Per https://github.com/golang/go/wiki/GoArm we need to set GOARM when
building for ARMv5, ARMv6 and ARMv7. The current code in go_map_arm()
does not account for the Cortex* TUNINGs and as such misses several
Cortex variants which implement ARMv7. Here we add an additional check
that will include Cortex-A5 through Cortex-A17 as ARMv7 variants
(ie. GOARM='7'). The Cortex-R and Cortex-M variants are also captured
even though there are no tunings for these currently (lack MMU support
so not supported).
Signed-off-by: Mark Asselstine
---
V2
* Cover all ARMv7 Cortex* variants
meta/classes/goarch.bbclass | 4
1 file changed, 4 insertions(+)
diff --git a/meta/classes/goarch.bbclass b/meta/classes/goarch.bbclass
index 39fea5e..84977a5 100644
--- a/meta/classes/goarch.bbclass
+++ b/meta/classes/goarch.bbclass
@@ -74,6 +74,10 @@ def go_map_arch(a, d):
def go_map_arm(a, f, d):
import re
if re.match('arm.*', a):
+for el in f.split():
+m = re.match("cortex[arm](\d.*)", el)
+if m and int(m.group(1)) < 32:
+ return '7'
if 'armv7' in f:
return '7'
elif 'armv6' in f:
--
2.7.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] libnss-nisplus: Add recipe
Same as with libnss-nis - this will substitute
the glibc nisplus module which has been removed
SRCREV points to 1.3 release plus patch on top which
allows to build with recent glibc versions
Signed-off-by: Ruslan Bilovol
---
.../libnss-nisplus/libnss-nisplus.bb | 31 ++
1 file changed, 31 insertions(+)
create mode 100644 meta/recipes-extended/libnss-nisplus/libnss-nisplus.bb
diff --git a/meta/recipes-extended/libnss-nisplus/libnss-nisplus.bb
b/meta/recipes-extended/libnss-nisplus/libnss-nisplus.bb
new file mode 100644
index 000..2dbeee7
--- /dev/null
+++ b/meta/recipes-extended/libnss-nisplus/libnss-nisplus.bb
@@ -0,0 +1,31 @@
+# Copyright (C) 2019 Ruslan Bilovol
+# Released under the MIT license (see COPYING.MIT for the terms)
+
+SUMMARY = "NSS module for glibc, to provide NIS+ support for glibc"
+
+DESCRIPTION = "This package contains the NSS NIS+ plugin for glibc.\
+This code was formerly part of glibc, but is now standalone to\
+be able to link against TI-RPC for IPv6 support."
+
+HOMEPAGE = "https://github.com/thkukuk/libnss_nisplus";
+LICENSE = "LGPL-2.1"
+LIC_FILES_CHKSUM = "file://COPYING;md5=4fbd65380cdd255951079008b364516c"
+SECTION = "libs"
+DEPENDS += "libtirpc libnsl2"
+
+PV = "1.3+git${SRCPV}"
+
+SRCREV = "c6934373c7bac91499ff7bbe7d2439599325ca63"
+
+SRC_URI = "git://github.com/thkukuk/libnss_nisplus \
+ "
+
+S = "${WORKDIR}/git"
+
+inherit autotools pkgconfig
+
+BBCLASSEXTEND += "native nativesdk"
+#
+# We will skip parsing this packagegeoup for non-glibc systems
+#
+COMPATIBLE_HOST_libc-musl = 'null'
--
1.9.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [oe-core][PATCH 1/1] puzzles: fix uninitialized variable compiler error
Can we *please* start sending these upstream. It's not like the
maintainer isn't responsive.
Ross
On Thu, 14 Mar 2019 at 19:20, Joe Slater wrote:
>
> In tree234.c, change a while() loop to a for() loop so
> that the compiler will realize we loop at least once.
>
> Signed-off-by: Joe Slater
> ---
> .../puzzles/files/fix-ki-uninitialized.patch | 25
> ++
> meta/recipes-sato/puzzles/puzzles_git.bb | 1 +
> 2 files changed, 26 insertions(+)
> create mode 100644 meta/recipes-sato/puzzles/files/fix-ki-uninitialized.patch
>
> diff --git a/meta/recipes-sato/puzzles/files/fix-ki-uninitialized.patch
> b/meta/recipes-sato/puzzles/files/fix-ki-uninitialized.patch
> new file mode 100644
> index 000..7218d62
> --- /dev/null
> +++ b/meta/recipes-sato/puzzles/files/fix-ki-uninitialized.patch
> @@ -0,0 +1,25 @@
> +puzzles: avoid compiler unitialized variable error
> +
> +The compiler does not realize that we must go through the while()
> +loop at least once, so we replace it with a for() loop.
> +
> +Upstream-Status: Pending
> +
> +Signed-off-by: Joe Slater
> +
> +--- a/tree234.c
> b/tree234.c
> +@@ -326,8 +326,11 @@ static void *add234_internal(tree234 *t,
> + return orig_e;
> + }
> +
> +-n = t->root;
> +-while (n) {
> ++/*
> ++ * We know t->root is not NULL. The logic
> ++ * to break out of this is at the end of the loop.
> ++ */
> ++for (n = t->root;;) {
> + LOG((" node %p: %p/%d \"%s\" %p/%d \"%s\" %p/%d \"%s\" %p/%d\n",
> +n,
> +n->kids[0], n->counts[0], n->elems[0],
> diff --git a/meta/recipes-sato/puzzles/puzzles_git.bb
> b/meta/recipes-sato/puzzles/puzzles_git.bb
> index 0766bd4..59b9525 100644
> --- a/meta/recipes-sato/puzzles/puzzles_git.bb
> +++ b/meta/recipes-sato/puzzles/puzzles_git.bb
> @@ -14,6 +14,7 @@ SRC_URI = "git://git.tartarus.org/simon/puzzles.git \
> file://0001-palisade-Fix-warnings-with-clang-on-arm.patch \
>
> file://0001-Use-Wno-error-format-overflow-if-the-compiler-suppor.patch \
>
> file://0001-pattern.c-Change-string-lenght-parameter-to-be-size_.patch \
> + file://fix-ki-uninitialized.patch \
> "
>
> UPSTREAM_CHECK_COMMITS = "1"
> --
> 2.7.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
[OE-core] [oe-core][PATCH 1/1] puzzles: fix uninitialized variable compiler error
In tree234.c, change a while() loop to a for() loop so
that the compiler will realize we loop at least once.
Signed-off-by: Joe Slater
---
.../puzzles/files/fix-ki-uninitialized.patch | 25 ++
meta/recipes-sato/puzzles/puzzles_git.bb | 1 +
2 files changed, 26 insertions(+)
create mode 100644 meta/recipes-sato/puzzles/files/fix-ki-uninitialized.patch
diff --git a/meta/recipes-sato/puzzles/files/fix-ki-uninitialized.patch
b/meta/recipes-sato/puzzles/files/fix-ki-uninitialized.patch
new file mode 100644
index 000..7218d62
--- /dev/null
+++ b/meta/recipes-sato/puzzles/files/fix-ki-uninitialized.patch
@@ -0,0 +1,25 @@
+puzzles: avoid compiler unitialized variable error
+
+The compiler does not realize that we must go through the while()
+loop at least once, so we replace it with a for() loop.
+
+Upstream-Status: Pending
+
+Signed-off-by: Joe Slater
+
+--- a/tree234.c
b/tree234.c
+@@ -326,8 +326,11 @@ static void *add234_internal(tree234 *t,
+ return orig_e;
+ }
+
+-n = t->root;
+-while (n) {
++/*
++ * We know t->root is not NULL. The logic
++ * to break out of this is at the end of the loop.
++ */
++for (n = t->root;;) {
+ LOG((" node %p: %p/%d \"%s\" %p/%d \"%s\" %p/%d \"%s\" %p/%d\n",
+n,
+n->kids[0], n->counts[0], n->elems[0],
diff --git a/meta/recipes-sato/puzzles/puzzles_git.bb
b/meta/recipes-sato/puzzles/puzzles_git.bb
index 0766bd4..59b9525 100644
--- a/meta/recipes-sato/puzzles/puzzles_git.bb
+++ b/meta/recipes-sato/puzzles/puzzles_git.bb
@@ -14,6 +14,7 @@ SRC_URI = "git://git.tartarus.org/simon/puzzles.git \
file://0001-palisade-Fix-warnings-with-clang-on-arm.patch \
file://0001-Use-Wno-error-format-overflow-if-the-compiler-suppor.patch \
file://0001-pattern.c-Change-string-lenght-parameter-to-be-size_.patch \
+ file://fix-ki-uninitialized.patch \
"
UPSTREAM_CHECK_COMMITS = "1"
--
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/2] go.bbclass: Export GOARM
On Thursday, March 14, 2019 2:44:35 PM EDT Christopher Larson wrote:
> Good to know, thanks. Possibly something to improve in bitbake at some
> point in the future.
This is what I am preparing to send out
---
GOARM[export] = "0"
GOARM_arm_class-target = "${TARGET_GOARM}"
GOARM_arm_class-target[export] = "1"
---
This should address Mark Hatle's concerns about GOARM being undefined/have
deterministic behavior. For non-'arm' the export simply won't be present so it
doesn't matter what GOARM is, for 'arm' we get what we want. And I get what I
was aiming for, no environment pollution in run.do_compile and friends for
non-'arm'.
I know it isn't really used elsewhere but I don't believe I am making any
assumptions or using things in a way they shouldn't be used. At any rate I
will send this out in 20 minutes or so and we'll see how it stands up.
MarkA
>
> On Thu, Mar 14, 2019 at 11:32 AM Mark Asselstine <
>
> mark.asselst...@windriver.com> wrote:
> > On Wednesday, March 13, 2019 3:40:18 PM EDT Christopher Larson wrote:
> > > How would bitbake respond to an ‘export’ line with the empty string?
> > > I.e.
> > > can you do an actual conditional export the way we do conditional
> >
> > inherits,
> >
> > > so it still is only exported for arm, even if the value is set to the
> >
> > empty
> >
> > > string for others?
> >
> > Unfortunately no. It is a parsing error.
> >
> > I am working on alternatives and will hopefully have something out
> > shortly.
> >
> > MarkA
> >
> > > On Wed, Mar 13, 2019 at 10:57 AM Mark Asselstine <
> > >
> > > mark.asselst...@windriver.com> wrote:
> > > > When building GO packages for ARM (v5, v6, v7) it is expected that the
> > > > GOARM env variable is set during the build. Not having GOARM exported
> > > > will result in GO binaries which can't be executed on the target
> > > > (terminate with segfault). Per https://github.com/golang/go/wiki/GoArm
> > > >
> > > > We already have the logic in goarch.bbclass to determine the correct
> > > > value of GOARM (see GOARM_TARGET), but currently this is only used to
> > > > build go itself (go-cross_1.*.bb requires go-cross.inc --> export
> > > > GOARM = "${TARGET_GOARM}").
> > > >
> > > > Here we export GOARM but we do it such that it is only exported if we
> > > > are building for 'arm' and only when recipes requiring/inheriting
> > > > go.bbclass are be used to build for the target.
> > > >
> > > > Signed-off-by: Mark Asselstine
> > > > ---
> > > >
> > > > Richard,
> > > >
> > > > MarkH and I were debating this one some. He was suggesting I add
> > > > 'GOARM ?= ""' so as not to leave things undefined for non-arm target
> > > > builds. I however, like the behavior of this as submitted here as
> > > > non-arm target builds don't get polluted with a useless export in
> > > > their do_compile scripts and such. The question is as presented here
> > > > is the behavior deterministic?
> > > >
> > > >
> > > > meta/classes/go.bbclass | 3 +++
> > > >
> > > > 1 file changed, 3 insertions(+)
> > > >
> > > > diff --git a/meta/classes/go.bbclass b/meta/classes/go.bbclass
> > > > index af331f8..72e2c29 100644
> > > > --- a/meta/classes/go.bbclass
> > > > +++ b/meta/classes/go.bbclass
> > > > @@ -8,6 +8,9 @@ GOROOT = "${STAGING_LIBDIR}/go"
> > > >
> > > > export GOROOT
> > > > export GOROOT_FINAL = "${libdir}/go"
> > > >
> > > > +GOARM_arm_class-target = "${TARGET_GOARM}"
> > > > +export GOARM
> > > > +
> > > >
> > > > DEPENDS_GOLANG_class-target = "virtual/${TUNE_PKGARCH}-go
> > > >
> > > > virtual/${TARGET_PREFIX}go-runtime"
> > > >
> > > > DEPENDS_GOLANG_class-native = "go-native"
> > > > DEPENDS_GOLANG_class-nativesdk = "virtual/${TARGET_PREFIX}go-crosssdk
> > > >
> > > > virtual/${TARGET_PREFIX}go-runtime"
> > > > --
> > > > 2.7.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] [PATCH 1/2] go.bbclass: Export GOARM
Good to know, thanks. Possibly something to improve in bitbake at some
point in the future.
On Thu, Mar 14, 2019 at 11:32 AM Mark Asselstine <
mark.asselst...@windriver.com> wrote:
> On Wednesday, March 13, 2019 3:40:18 PM EDT Christopher Larson wrote:
> > How would bitbake respond to an ‘export’ line with the empty string? I.e.
> > can you do an actual conditional export the way we do conditional
> inherits,
> > so it still is only exported for arm, even if the value is set to the
> empty
> > string for others?
>
> Unfortunately no. It is a parsing error.
>
> I am working on alternatives and will hopefully have something out shortly.
>
> MarkA
>
> >
> > On Wed, Mar 13, 2019 at 10:57 AM Mark Asselstine <
> >
> > mark.asselst...@windriver.com> wrote:
> > > When building GO packages for ARM (v5, v6, v7) it is expected that the
> > > GOARM env variable is set during the build. Not having GOARM exported
> > > will result in GO binaries which can't be executed on the target
> > > (terminate with segfault). Per https://github.com/golang/go/wiki/GoArm
> > >
> > > We already have the logic in goarch.bbclass to determine the correct
> > > value of GOARM (see GOARM_TARGET), but currently this is only used to
> > > build go itself (go-cross_1.*.bb requires go-cross.inc --> export
> > > GOARM = "${TARGET_GOARM}").
> > >
> > > Here we export GOARM but we do it such that it is only exported if we
> > > are building for 'arm' and only when recipes requiring/inheriting
> > > go.bbclass are be used to build for the target.
> > >
> > > Signed-off-by: Mark Asselstine
> > > ---
> > >
> > > Richard,
> > >
> > > MarkH and I were debating this one some. He was suggesting I add
> > > 'GOARM ?= ""' so as not to leave things undefined for non-arm target
> > > builds. I however, like the behavior of this as submitted here as
> > > non-arm target builds don't get polluted with a useless export in
> > > their do_compile scripts and such. The question is as presented here
> > > is the behavior deterministic?
> > >
> > >
> > > meta/classes/go.bbclass | 3 +++
> > >
> > > 1 file changed, 3 insertions(+)
> > >
> > > diff --git a/meta/classes/go.bbclass b/meta/classes/go.bbclass
> > > index af331f8..72e2c29 100644
> > > --- a/meta/classes/go.bbclass
> > > +++ b/meta/classes/go.bbclass
> > > @@ -8,6 +8,9 @@ GOROOT = "${STAGING_LIBDIR}/go"
> > >
> > > export GOROOT
> > > export GOROOT_FINAL = "${libdir}/go"
> > >
> > > +GOARM_arm_class-target = "${TARGET_GOARM}"
> > > +export GOARM
> > > +
> > >
> > > DEPENDS_GOLANG_class-target = "virtual/${TUNE_PKGARCH}-go
> > >
> > > virtual/${TARGET_PREFIX}go-runtime"
> > >
> > > DEPENDS_GOLANG_class-native = "go-native"
> > > DEPENDS_GOLANG_class-nativesdk = "virtual/${TARGET_PREFIX}go-crosssdk
> > >
> > > virtual/${TARGET_PREFIX}go-runtime"
> > > --
> > > 2.7.4
> > >
> > > --
> > > ___
> > > Openembedded-core mailing list
> > > Openembedded-core@lists.openembedded.org
> > > http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
>
>
>
>
--
Christopher Larson
kergoth at gmail dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Senior Software Engineer, Mentor Graphics
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/2] go.bbclass: Export GOARM
On Wednesday, March 13, 2019 3:40:18 PM EDT Christopher Larson wrote:
> How would bitbake respond to an ‘export’ line with the empty string? I.e.
> can you do an actual conditional export the way we do conditional inherits,
> so it still is only exported for arm, even if the value is set to the empty
> string for others?
Unfortunately no. It is a parsing error.
I am working on alternatives and will hopefully have something out shortly.
MarkA
>
> On Wed, Mar 13, 2019 at 10:57 AM Mark Asselstine <
>
> mark.asselst...@windriver.com> wrote:
> > When building GO packages for ARM (v5, v6, v7) it is expected that the
> > GOARM env variable is set during the build. Not having GOARM exported
> > will result in GO binaries which can't be executed on the target
> > (terminate with segfault). Per https://github.com/golang/go/wiki/GoArm
> >
> > We already have the logic in goarch.bbclass to determine the correct
> > value of GOARM (see GOARM_TARGET), but currently this is only used to
> > build go itself (go-cross_1.*.bb requires go-cross.inc --> export
> > GOARM = "${TARGET_GOARM}").
> >
> > Here we export GOARM but we do it such that it is only exported if we
> > are building for 'arm' and only when recipes requiring/inheriting
> > go.bbclass are be used to build for the target.
> >
> > Signed-off-by: Mark Asselstine
> > ---
> >
> > Richard,
> >
> > MarkH and I were debating this one some. He was suggesting I add
> > 'GOARM ?= ""' so as not to leave things undefined for non-arm target
> > builds. I however, like the behavior of this as submitted here as
> > non-arm target builds don't get polluted with a useless export in
> > their do_compile scripts and such. The question is as presented here
> > is the behavior deterministic?
> >
> >
> > meta/classes/go.bbclass | 3 +++
> >
> > 1 file changed, 3 insertions(+)
> >
> > diff --git a/meta/classes/go.bbclass b/meta/classes/go.bbclass
> > index af331f8..72e2c29 100644
> > --- a/meta/classes/go.bbclass
> > +++ b/meta/classes/go.bbclass
> > @@ -8,6 +8,9 @@ GOROOT = "${STAGING_LIBDIR}/go"
> >
> > export GOROOT
> > export GOROOT_FINAL = "${libdir}/go"
> >
> > +GOARM_arm_class-target = "${TARGET_GOARM}"
> > +export GOARM
> > +
> >
> > DEPENDS_GOLANG_class-target = "virtual/${TUNE_PKGARCH}-go
> >
> > virtual/${TARGET_PREFIX}go-runtime"
> >
> > DEPENDS_GOLANG_class-native = "go-native"
> > DEPENDS_GOLANG_class-nativesdk = "virtual/${TARGET_PREFIX}go-crosssdk
> >
> > virtual/${TARGET_PREFIX}go-runtime"
> > --
> > 2.7.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][Thud][PATCH 1/3] lttng-ust: update to 2.10.3
> > Disregard this series. It does not follow the project guideline regarding > > recipe > > update for stable release. > There are exceptions when a package update is a bugfix only change. I > know the kernel, openssl, bind, curl and a few others fall into that > category. Many minor version updates tend to be bug fix only but that > all depends on the upstream project policies. Binutils does not follow > that scheme as they add features in minor version updates. This is what > I know from personal experience. What helps the project along with the > maintainer is having a brief summary of the changes in the commit > message. I am at the mercy of commit message. I get that. I assumed that most project are *sane* and stick to something similar to SemVer. Sorry for that. We follow SemVer [1] for the following projects: Babeltrace LTTng-tools LTTng-ust LTTng-modules userspace-rcu This series contains only PATCH level update (MAJOR.MINOR.PATCH). You will note that the lttng-tools recipes was not updated to the 2.10.x release in this series. Side note, as a project (lttng) we recommend that lttng-tools and lttng-ust be upgraded in lockstep (MINOR == MINOR). But since we also conform to SemVer there is no problem using an older MINOR version of lttng-tools with a newer MINOR version of lttng-ust. The other way around is not recommended and will simply not build most of the time. lttng-modules is *special* since we fix thing to allow support of newer kernel as time goes by. Again, we do not add features across PATCH level release. Still, I think I understand a bit more the constraint oe-core and yocto stable branch are facing and would not mind if the recipes stay at the version they are now. [1] https://semver.org/ > > Can you confirm this is bug fix only update? > Yes it is. Cheers -- Jonathan Rajotte-Julien EfficiOS -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [sumo][PATCH] coreutils: 8.29: fix native build
This fixes the native build on glibc 2.28 hosts, by backporting two
gnulib patches from master.
Signed-off-by: Stefan Müller-Klieser
---
...adjust-to-glibc-2.28-libio.h-removal.patch | 193 ++
...e-more-paranoid-about-libio.h-change.patch | 187 +
meta/recipes-core/coreutils/coreutils_8.29.bb | 2 +
3 files changed, 382 insertions(+)
create mode 100644
meta/recipes-core/coreutils/coreutils/0001-fflush-adjust-to-glibc-2.28-libio.h-removal.patch
create mode 100644
meta/recipes-core/coreutils/coreutils/0002-fflush-be-more-paranoid-about-libio.h-change.patch
diff --git
a/meta/recipes-core/coreutils/coreutils/0001-fflush-adjust-to-glibc-2.28-libio.h-removal.patch
b/meta/recipes-core/coreutils/coreutils/0001-fflush-adjust-to-glibc-2.28-libio.h-removal.patch
new file mode 100644
index ..110b34372db1
--- /dev/null
+++
b/meta/recipes-core/coreutils/coreutils/0001-fflush-adjust-to-glibc-2.28-libio.h-removal.patch
@@ -0,0 +1,193 @@
+From 269a8987224ec62b7a9aa6202772b07d5be424d2 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Stefan=20M=C3=BCller-Klieser?=
+Date: Mon, 11 Mar 2019 16:00:33 +0100
+Subject: [PATCH 1/2] fflush: adjust to glibc 2.28 libio.h removal
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+Backport of patch:
+4af4a4a71827c0bc5e0ec67af23edef4f15cee8e
+Paul Eggert
+fflush: adjust to glibc 2.28 libio.h removal
+
+Upstream-Status: Backport [master]
+
+Signed-off-by: Stefan Müller-Klieser
+---
+ lib/fflush.c | 6 +++---
+ lib/fpending.c | 2 +-
+ lib/fpurge.c | 2 +-
+ lib/freadahead.c | 2 +-
+ lib/freading.c | 2 +-
+ lib/freadptr.c | 2 +-
+ lib/freadseek.c | 2 +-
+ lib/fseeko.c | 4 ++--
+ lib/fseterr.c| 2 +-
+ lib/stdio-impl.h | 6 ++
+ 10 files changed, 18 insertions(+), 12 deletions(-)
+
+diff --git a/lib/fflush.c b/lib/fflush.c
+index 4e65692644b1..c16da5fdcf23 100644
+--- a/lib/fflush.c
b/lib/fflush.c
+@@ -33,7 +33,7 @@
+ #undef fflush
+
+
+-#if defined _IO_ftrylockfile || __GNU_LIBRARY__ == 1 /* GNU libc, BeOS,
Haiku, Linux libc5 */
++#if defined _IO_EOF_SEEN || __GNU_LIBRARY__ == 1 /* GNU libc, BeOS, Haiku,
Linux libc5 */
+
+ /* Clear the stream's ungetc buffer, preserving the value of ftello (fp). */
+ static void
+@@ -72,7 +72,7 @@ clear_ungetc_buffer (FILE *fp)
+
+ #endif
+
+-#if ! (defined _IO_ftrylockfile || __GNU_LIBRARY__ == 1 /* GNU libc, BeOS,
Haiku, Linux libc5 */)
++#if ! (defined _IO_EOF_SEEN || __GNU_LIBRARY__ == 1 /* GNU libc, BeOS, Haiku,
Linux libc5 */)
+
+ # if (defined __sferror || defined __DragonFly__ || defined __ANDROID__) &&
defined __SNPT
+ /* FreeBSD, NetBSD, OpenBSD, DragonFly, Mac OS X, Cygwin, Minix 3, Android */
+@@ -148,7 +148,7 @@ rpl_fflush (FILE *stream)
+ if (stream == NULL || ! freading (stream))
+ return fflush (stream);
+
+-#if defined _IO_ftrylockfile || __GNU_LIBRARY__ == 1 /* GNU libc, BeOS,
Haiku, Linux libc5 */
++#if defined _IO_EOF_SEEN || __GNU_LIBRARY__ == 1 /* GNU libc, BeOS, Haiku,
Linux libc5 */
+
+ clear_ungetc_buffer_preserving_position (stream);
+
+diff --git a/lib/fpending.c b/lib/fpending.c
+index 5811a4a74750..9e21a165e220 100644
+--- a/lib/fpending.c
b/lib/fpending.c
+@@ -32,7 +32,7 @@ __fpending (FILE *fp)
+ /* Most systems provide FILE as a struct and the necessary bitmask in
+ , because they need it for implementing getc() and putc() as
+ fast macros. */
+-#if defined _IO_ftrylockfile || __GNU_LIBRARY__ == 1 /* GNU libc, BeOS,
Haiku, Linux libc5 */
++#if defined _IO_EOF_SEEN || __GNU_LIBRARY__ == 1 /* GNU libc, BeOS, Haiku,
Linux libc5 */
+ return fp->_IO_write_ptr - fp->_IO_write_base;
+ #elif defined __sferror || defined __DragonFly__ || defined __ANDROID__
+ /* FreeBSD, NetBSD, OpenBSD, DragonFly, Mac OS X, Cygwin, Minix 3, Android
*/
+diff --git a/lib/fpurge.c b/lib/fpurge.c
+index 408b8fcbb3b8..3a160004d49d 100644
+--- a/lib/fpurge.c
b/lib/fpurge.c
+@@ -62,7 +62,7 @@ fpurge (FILE *fp)
+ /* Most systems provide FILE as a struct and the necessary bitmask in
+ , because they need it for implementing getc() and putc() as
+ fast macros. */
+-# if defined _IO_ftrylockfile || __GNU_LIBRARY__ == 1 /* GNU libc, BeOS,
Haiku, Linux libc5 */
++# if defined _IO_EOF_SEEN || __GNU_LIBRARY__ == 1 /* GNU libc, BeOS, Haiku,
Linux libc5 */
+ fp->_IO_read_end = fp->_IO_read_ptr;
+ fp->_IO_write_ptr = fp->_IO_write_base;
+ /* Avoid memory leak when there is an active ungetc buffer. */
+diff --git a/lib/freadahead.c b/lib/freadahead.c
+index f335f041ee5e..e7cb77b6722b 100644
+--- a/lib/freadahead.c
b/lib/freadahead.c
+@@ -30,7 +30,7 @@ extern size_t __sreadahead (FILE *);
+ size_t
+ freadahead (FILE *fp)
+ {
+-#if defined _IO_ftrylockfile || __GNU_LIBRARY__ == 1 /* GNU libc, BeOS,
Haiku, Linux libc5 */
++#if defined _IO_EOF_SEEN || __GNU_LIBRARY__ == 1 /* GNU libc, BeOS, Haiku,
Linux libc5 */
+ if (fp->_IO_write_ptr > fp->_IO_write_base)
+ r
Re: [OE-core] [OE-Core][Thud][PATCH 1/3] lttng-ust: update to 2.10.3
Jonathan,
On 3/13/19 3:47 PM, Jonathan Rajotte-Julien wrote:
> Hi,
>
> Disregard this series. It does not follow the project guideline regarding
> recipe
> update for stable release.
There are exceptions when a package update is a bugfix only change. I
know the kernel, openssl, bind, curl and a few others fall into that
category. Many minor version updates tend to be bug fix only but that
all depends on the upstream project policies. Binutils does not follow
that scheme as they add features in minor version updates. This is what
I know from personal experience. What helps the project along with the
maintainer is having a brief summary of the changes in the commit
message. I am at the mercy of commit message.
Can you confirm this is bug fix only update?
regards,
Armin
> Thanks
>
> On Wed, Mar 13, 2019 at 08:55:53PM +, Jonathan Rajotte wrote:
>> Signed-off-by: Jonathan Rajotte
>> ---
>> .../lttng/{lttng-ust_2.10.1.bb => lttng-ust_2.10.3.bb}| 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>> rename meta/recipes-kernel/lttng/{lttng-ust_2.10.1.bb =>
>> lttng-ust_2.10.3.bb} (90%)
>>
>> diff --git a/meta/recipes-kernel/lttng/lttng-ust_2.10.1.bb
>> b/meta/recipes-kernel/lttng/lttng-ust_2.10.3.bb
>> similarity index 90%
>> rename from meta/recipes-kernel/lttng/lttng-ust_2.10.1.bb
>> rename to meta/recipes-kernel/lttng/lttng-ust_2.10.3.bb
>> index d79a47931c..b5c43200d6 100644
>> --- a/meta/recipes-kernel/lttng/lttng-ust_2.10.1.bb
>> +++ b/meta/recipes-kernel/lttng/lttng-ust_2.10.3.bb
>> @@ -23,8 +23,8 @@ PE = "2"
>> SRC_URI = "https://lttng.org/files/lttng-ust/lttng-ust-${PV}.tar.bz2 \
>> file://lttng-ust-doc-examples-disable.patch \
>>"
>> -SRC_URI[md5sum] = "4863cc2f9f0a070b42438bb646bbba06"
>> -SRC_URI[sha256sum] =
>> "07cc3c0b71e7b77f1913d5b7f340a78a9af414440e4662712aef2d635b88ee9d"
>> +SRC_URI[md5sum] = "ffcfa8c1ba9a52f002d240e936e9afa2"
>> +SRC_URI[sha256sum] =
>> "9e8420f90d5f963f7aa32bc6d44adc1e491136f687c69ffb7a3075d33b40852b"
>>
>> CVE_PRODUCT = "ust"
>>
>> --
>> 2.17.1
>>
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] networkmanager: Use ALTERNATIVES for resolv-conf handling.
From: Drew Moseley
This brings the networkmanager in sync with how systemd-resolved and connman
work. Additionally this allows it to function with a read-only rootFS.
Signed-off-by: Drew Moseley
---
.../networkmanager/networkmanager_1.14.4.bb | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git
a/meta-networking/recipes-connectivity/networkmanager/networkmanager_1.14.4.bb
b/meta-networking/recipes-connectivity/networkmanager/networkmanager_1.14.4.bb
index 26c40a5..86a5322 100644
---
a/meta-networking/recipes-connectivity/networkmanager/networkmanager_1.14.4.bb
+++
b/meta-networking/recipes-connectivity/networkmanager/networkmanager_1.14.4.bb
@@ -20,7 +20,7 @@ DEPENDS = " \
curl \
"
-inherit gnomebase gettext systemd bluetooth bash-completion vala
gobject-introspection gtk-doc
+inherit gnomebase gettext systemd bluetooth bash-completion vala
gobject-introspection gtk-doc update-alternatives
SRC_URI = " \
${GNOME_MIRROR}/NetworkManager/${@gnome_verdir("${PV}")}/NetworkManager-${PV}.tar.xz
\
@@ -138,6 +138,16 @@ FILES_${PN}-nmtui-doc = " \
SYSTEMD_SERVICE_${PN} = "NetworkManager.service
NetworkManager-dispatcher.service"
+ALTERNATIVE_PRIORITY = "100"
+ALTERNATIVE_${PN} =
"${@bb.utils.contains('DISTRO_FEATURES','systemd','resolv-conf','',d)}"
+ALTERNATIVE_TARGET[resolv-conf] =
"${@bb.utils.contains('DISTRO_FEATURES','systemd','${sysconfdir}/resolv-conf.NetworkManager','',d)}"
+ALTERNATIVE_LINK_NAME[resolv-conf] =
"${@bb.utils.contains('DISTRO_FEATURES','systemd','${sysconfdir}/resolv.conf','',d)}"
+
do_install_append() {
rm -rf ${D}/run ${D}${localstatedir}/run
+
+# For read-only filesystem, do not create links during bootup
+if ${@bb.utils.contains('DISTRO_FEATURES','systemd','true','false',d)};
then
+ln -sf ../run/NetworkManager/resolv.conf
${D}${sysconfdir}/resolv-conf.NetworkManager
+fi
}
--
2.7.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCHv4 1/2] Revert "arm-tunes: Remove -march option if mcpu is already added"
This reverts commit ac83d22eb5031f7fdd09d34a1a46d92fd3e39a3c.
This solution had unforeseen side effects, which, e.g., lead to the
following sanity error if trying to build with the arm926ejs default
tune:
Error, the PACKAGE_ARCHS variable (all any noarch arm armv4 armv4t
armv5 armv5t armv5e armv5te arm926ejste arm926ejse ) for DEFAULTTUNE (arm926ejs) does not contain
TUNE_PKGARCH (arm926ejst).
An alternative solution will follow, which only affects the -mcpu and
-march options without other side effects.
Signed-off-by: Peter Kjellerstedt
---
meta/conf/machine/include/tune-arm1136jf-s.inc | 4 +---
meta/conf/machine/include/tune-arm920t.inc | 4 +---
meta/conf/machine/include/tune-arm926ejs.inc | 4 +---
meta/conf/machine/include/tune-arm9tdmi.inc | 4 +---
meta/conf/machine/include/tune-cortexa15.inc | 27 ++-
meta/conf/machine/include/tune-cortexa17.inc | 27 ++-
meta/conf/machine/include/tune-cortexa5.inc | 27 ++-
meta/conf/machine/include/tune-cortexa7.inc | 27 ++-
meta/conf/machine/include/tune-cortexa8.inc | 19 +++-
meta/conf/machine/include/tune-cortexa9.inc | 28 ++--
meta/conf/machine/include/tune-ep9312.inc| 1 -
meta/conf/machine/include/tune-iwmmxt.inc| 3 +--
meta/conf/machine/include/tune-strongarm1100.inc | 3 +--
meta/conf/machine/include/tune-xscale.inc| 7 ++
14 files changed, 76 insertions(+), 109 deletions(-)
diff --git a/meta/conf/machine/include/tune-arm1136jf-s.inc
b/meta/conf/machine/include/tune-arm1136jf-s.inc
index d883eba7c9..c5de63e1cc 100644
--- a/meta/conf/machine/include/tune-arm1136jf-s.inc
+++ b/meta/conf/machine/include/tune-arm1136jf-s.inc
@@ -4,10 +4,8 @@ require conf/machine/include/arm/arch-armv6.inc
TUNEVALID[arm1136jfs] = "Enable arm1136jfs specific processor optimizations"
TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'arm1136jfs', '
-mcpu=arm1136jf-s', '', d)}"
-MACHINEOVERRIDES =. "${@bb.utils.contains('TUNE_FEATURES', 'arm1136jfs',
'armv6:', '' ,d)}"
AVAILTUNES += "arm1136jfs"
ARMPKGARCH_tune-arm1136jfs = "arm1136jfs"
-# mcpu is used so don't use armv6 as we don't want march
-TUNE_FEATURES_tune-arm1136jfs = "arm arm1136jfs"
+TUNE_FEATURES_tune-arm1136jfs = "${TUNE_FEATURES_tune-armv6} arm1136jfs"
PACKAGE_EXTRA_ARCHS_tune-arm1136jfs = "${PACKAGE_EXTRA_ARCHS_tune-armv6}
arm1136jfs-vfp"
diff --git a/meta/conf/machine/include/tune-arm920t.inc
b/meta/conf/machine/include/tune-arm920t.inc
index 42e8ed2b51..c6e74b6772 100644
--- a/meta/conf/machine/include/tune-arm920t.inc
+++ b/meta/conf/machine/include/tune-arm920t.inc
@@ -4,10 +4,8 @@ require conf/machine/include/arm/arch-armv4.inc
TUNEVALID[arm920t] = "Enable arm920t specific processor optimizations"
TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'arm920t', '
-mcpu=arm920t', '', d)}"
-MACHINEOVERRIDES =. "${@bb.utils.contains('TUNE_FEATURES', 'arm920t',
'armv4:', '' ,d)}"
AVAILTUNES += "arm920t"
ARMPKGARCH_tune-arm920t = "arm920t"
-# mcpu is used so don't use armv4t as we don't want march
-TUNE_FEATURES_tune-arm920t = "arm thumb arm920t"
+TUNE_FEATURES_tune-arm920t = "${TUNE_FEATURES_tune-armv4t} arm920t"
PACKAGE_EXTRA_ARCHS_tune-arm920t = "${PACKAGE_EXTRA_ARCHS_tune-armv4t} arm920t
arm920tt"
diff --git a/meta/conf/machine/include/tune-arm926ejs.inc
b/meta/conf/machine/include/tune-arm926ejs.inc
index 563d53bc4e..81bcda339b 100644
--- a/meta/conf/machine/include/tune-arm926ejs.inc
+++ b/meta/conf/machine/include/tune-arm926ejs.inc
@@ -4,10 +4,8 @@ require conf/machine/include/arm/arch-armv5-dsp.inc
TUNEVALID[arm926ejs] = "Enable arm926ejs specific processor optimizations"
TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'arm926ejs', '
-mcpu=arm926ej-s', '', d)}"
-MACHINEOVERRIDES =. "${@bb.utils.contains('TUNE_FEATURES', 'arm926ejs',
'armv5:', '' ,d)}"
AVAILTUNES += "arm926ejs"
ARMPKGARCH_tune-arm926ejs = "arm926ejs"
-# mcpu is used so don't use armv5te as we don't want march
-TUNE_FEATURES_tune-arm926ejs = "arm thumb dsp arm926ejs"
+TUNE_FEATURES_tune-arm926ejs = "${TUNE_FEATURES_tune-armv5te} arm926ejs"
PACKAGE_EXTRA_ARCHS_tune-arm926ejs = "${PACKAGE_EXTRA_ARCHS_tune-armv5te}
arm926ejste arm926ejse"
diff --git a/meta/conf/machine/include/tune-arm9tdmi.inc
b/meta/conf/machine/include/tune-arm9tdmi.inc
index e03a8b86a0..e9c2b8fcf5 100644
--- a/meta/conf/machine/include/tune-arm9tdmi.inc
+++ b/meta/conf/machine/include/tune-arm9tdmi.inc
@@ -4,10 +4,8 @@ require conf/machine/include/arm/arch-armv4.inc
TUNEVALID[arm9tdmi] = "Enable arm9tdmi specific processor optimizations"
TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'arm9tdmi', '
-mcpu=arm9tdmi', '', d)}"
-MACHINEOVERRIDES =. "${@bb.utils.contains('TUNE_FEATURES', 'arm9tdmi',
'armv4:', '' ,d)}"
AVAILTUNES += "arm9tdmi"
ARMPKGARCH_tune-arm9tdmi = "arm9tdmi"
-# mcpu is used so don
[OE-core] [PATCHv4 2/2] arm-tunes: Prefer the -mcpu option over -march
Tune files that inherit the arch definitions already define
appropriate -mcpu options, which are equivalent of the correct -march
and -mtune combinations. This is preferred since gcc is getting
stricter and stricter with option check semantics and can now find
incompatible -march and -mcpu options better with every release. It
does an internal feature consistency check and if it finds any
discrepancies between what -mcpu would expand to as compared to
-march, it will flag the options to be incompatible. For the naked eye
it looks wrong, but gcc will translate -mcpu to a given -march
internally and it might not match what we set in these arch files.
The effects are quite subtle, where this can result in configure tests
failing to compile due to these incompatible options and a feature
option getting disabled for a recipe for no reason.
E.g., with GCC 9, which can now detect that -mcpu=cortex-a5 and
-march=armv7-a are incompatible, many features in libstdc++ end up
disabled due to configure check failures, e.g., size_t size, ptrdiff_t
sizes, which in turn results in compiling libstdc++ with wanted
features disabled.
This is an alternative solution to the same problem originally
implemented by Khem Raj in commit ac83d22e, but this time only
affecting -mcpu and -march options without other side effects.
Signed-off-by: Peter Kjellerstedt
---
PATCHv2:
* Change all occurrences of TUNE_CCARGS into TUNE_MARCH in
arch-armv8a.inc
PATCHv3:
* Renamed TUNE_MCPU and TUNE_MARCH to TUNE_CCARGS_MCPU and
TUNE_CCARGS_MARCH to better match already existing variables, such
as TUNE_CCARGS_MFPU.
* Added TUNE_CCARGS_FEATURES to handle the extra mcpu/march features
specified for armv8a/aarch64.
PATCHv4:
* Renamed TUNE_CCARGS_FEATURES to TUNE_CCARGS_ARMV8A_FEATURES and use it
together with each -mpu or -march that needs it. This should avoid any
potential problems in case multiple tuning files are included. It also
makes it explicit that these features are added to the -mcpu and
-march options, which was only implicit before.
meta/conf/machine/include/arm/arch-arm.inc | 5 +
meta/conf/machine/include/arm/arch-armv4.inc | 2 +-
meta/conf/machine/include/arm/arch-armv5.inc | 2 +-
meta/conf/machine/include/arm/arch-armv6.inc | 2 +-
meta/conf/machine/include/arm/arch-armv7a.inc| 2 +-
meta/conf/machine/include/arm/arch-armv7ve.inc | 2 +-
meta/conf/machine/include/arm/arch-armv8a.inc| 13 +++--
meta/conf/machine/include/tune-arm1136jf-s.inc | 2 +-
meta/conf/machine/include/tune-arm920t.inc | 2 +-
meta/conf/machine/include/tune-arm926ejs.inc | 2 +-
meta/conf/machine/include/tune-arm9tdmi.inc | 2 +-
meta/conf/machine/include/tune-cortexa15.inc | 2 +-
meta/conf/machine/include/tune-cortexa17.inc | 2 +-
meta/conf/machine/include/tune-cortexa32.inc | 2 +-
meta/conf/machine/include/tune-cortexa35.inc | 2 +-
meta/conf/machine/include/tune-cortexa5.inc | 2 +-
meta/conf/machine/include/tune-cortexa53.inc | 2 +-
meta/conf/machine/include/tune-cortexa7.inc | 2 +-
meta/conf/machine/include/tune-cortexa72.inc | 2 +-
meta/conf/machine/include/tune-cortexa8.inc | 2 +-
meta/conf/machine/include/tune-cortexa9.inc | 2 +-
meta/conf/machine/include/tune-ep9312.inc| 2 +-
meta/conf/machine/include/tune-iwmmxt.inc| 2 +-
meta/conf/machine/include/tune-strongarm1100.inc | 2 +-
meta/conf/machine/include/tune-thunderx.inc | 2 +-
meta/conf/machine/include/tune-xscale.inc| 2 +-
26 files changed, 36 insertions(+), 30 deletions(-)
diff --git a/meta/conf/machine/include/arm/arch-arm.inc
b/meta/conf/machine/include/arm/arch-arm.inc
index 99625d8417..8144b5dd0d 100644
--- a/meta/conf/machine/include/arm/arch-arm.inc
+++ b/meta/conf/machine/include/arm/arch-arm.inc
@@ -11,6 +11,11 @@ ARMPKGSFX_THUMB ??= ""
TUNE_ARCH = "${@bb.utils.contains('TUNE_FEATURES', 'bigendian', 'armeb',
'arm', d)}"
TUNE_PKGARCH =
"${ARMPKGARCH}${ARMPKGSFX_THUMB}${ARMPKGSFX_DSP}${ARMPKGSFX_EABI}${ARMPKGSFX_ENDIAN}${ARMPKGSFX_FPU}"
+# Prefer -mcpu= over -arch=
+TUNE_CCARGS_MCPU ??= ""
+TUNE_CCARGS_MARCH ??= ""
+TUNE_CCARGS .= "${@d.getVar('TUNE_CCARGS_MCPU') or
d.getVar('TUNE_CCARGS_MARCH')}"
+
ABIEXTENSION = "eabi"
TARGET_FPU = "${@d.getVar('TUNE_CCARGS_MFLOAT') or 'soft'}"
diff --git a/meta/conf/machine/include/arm/arch-armv4.inc
b/meta/conf/machine/include/arm/arch-armv4.inc
index 47a7ad2830..dac791e308 100644
--- a/meta/conf/machine/include/arm/arch-armv4.inc
+++ b/meta/conf/machine/include/arm/arch-armv4.inc
@@ -2,7 +2,7 @@ DEFAULTTUNE ?= "armv4"
TUNEVALID[arm] = "Enable ARM instruction set"
TUNEVALID[armv4] = "Enable instructions for ARMv4"
-TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'armv4', '
-march=armv4t', '', d)}"
+TUNE_CCARGS_MARCH .= "${@bb.utils.contains('TUNE_FEATURES', 'armv4', '
-march=armv4t', '', d)}"
# enable --fix-v4bx when we have armv4 in TUNE_FE
[OE-core] [PATCH] zlib: cleanup
Drop remove.ldconfig.call.patch, as it's easier to just set LDCONFIG=true.
Pass uname=GNU via the documented configure option instead of undocumented
environment variable.
Rename zlib-1.2.11/ to just zlib/ as we don't ship multiple versions.
Send ldflags-tests.patch upstream and update Upstream-Status.
Signed-off-by: Ross Burton
---
.../zlib/zlib-1.2.11/remove.ldconfig.call.patch | 21 -
.../{zlib-1.2.11 => zlib}/Makefile-runtests.patch | 0
.../zlib/{zlib-1.2.11 => zlib}/ldflags-tests.patch | 4 ++--
.../zlib/{zlib-1.2.11 => zlib}/run-ptest| 0
meta/recipes-core/zlib/zlib_1.2.11.bb | 3 +--
5 files changed, 3 insertions(+), 25 deletions(-)
delete mode 100644
meta/recipes-core/zlib/zlib-1.2.11/remove.ldconfig.call.patch
rename meta/recipes-core/zlib/{zlib-1.2.11 => zlib}/Makefile-runtests.patch
(100%)
rename meta/recipes-core/zlib/{zlib-1.2.11 => zlib}/ldflags-tests.patch (91%)
rename meta/recipes-core/zlib/{zlib-1.2.11 => zlib}/run-ptest (100%)
diff --git a/meta/recipes-core/zlib/zlib-1.2.11/remove.ldconfig.call.patch
b/meta/recipes-core/zlib/zlib-1.2.11/remove.ldconfig.call.patch
deleted file mode 100644
index 7ccbe1f44c6..000
--- a/meta/recipes-core/zlib/zlib-1.2.11/remove.ldconfig.call.patch
+++ /dev/null
@@ -1,21 +0,0 @@
-
-When /etc/ld.so.cache is writeable by user running bitbake then it creates
invalid cache
-(in my case libstdc++.so cannot be found after building zlib(-native) and I
have to call
-touch */libstdc++.so && /sbin/ldconfig to fix it.
-
-So remove ldconfig call from make install-libs
-
-Upstream-Status: Inappropriate [disable feature]
-
-Index: zlib-1.2.11/Makefile.in
-===
zlib-1.2.11.orig/Makefile.in
-+++ zlib-1.2.11/Makefile.in
-@@ -322,7 +322,6 @@ install-libs: $(LIBS)
- rm -f $(DESTDIR)$(sharedlibdir)/$(SHAREDLIB)
$(DESTDIR)$(sharedlibdir)/$(SHAREDLIBM); \
- ln -s $(SHAREDLIBV) $(DESTDIR)$(sharedlibdir)/$(SHAREDLIB); \
- ln -s $(SHAREDLIBV) $(DESTDIR)$(sharedlibdir)/$(SHAREDLIBM); \
--($(LDCONFIG) || true) >/dev/null 2>&1; \
- fi
- rm -f $(DESTDIR)$(man3dir)/zlib.3
- cp $(SRCDIR)zlib.3 $(DESTDIR)$(man3dir)
diff --git a/meta/recipes-core/zlib/zlib-1.2.11/Makefile-runtests.patch
b/meta/recipes-core/zlib/zlib/Makefile-runtests.patch
similarity index 100%
rename from meta/recipes-core/zlib/zlib-1.2.11/Makefile-runtests.patch
rename to meta/recipes-core/zlib/zlib/Makefile-runtests.patch
diff --git a/meta/recipes-core/zlib/zlib-1.2.11/ldflags-tests.patch
b/meta/recipes-core/zlib/zlib/ldflags-tests.patch
similarity index 91%
rename from meta/recipes-core/zlib/zlib-1.2.11/ldflags-tests.patch
rename to meta/recipes-core/zlib/zlib/ldflags-tests.patch
index 19c40b74529..286390665f0 100644
--- a/meta/recipes-core/zlib/zlib-1.2.11/ldflags-tests.patch
+++ b/meta/recipes-core/zlib/zlib/ldflags-tests.patch
@@ -1,7 +1,7 @@
Obey LDFLAGS for tests
-Signed-off-by: Christopher Larson
-Upstream-Status: Pending
+Upstream-Status: Submitted [https://github.com/madler/zlib/pull/409]
+Signed-off-by: Ross Burton
--- zlib-1.2.8.orig/Makefile.in
+++ zlib-1.2.8/Makefile.in
diff --git a/meta/recipes-core/zlib/zlib-1.2.11/run-ptest
b/meta/recipes-core/zlib/zlib/run-ptest
similarity index 100%
rename from meta/recipes-core/zlib/zlib-1.2.11/run-ptest
rename to meta/recipes-core/zlib/zlib/run-ptest
diff --git a/meta/recipes-core/zlib/zlib_1.2.11.bb
b/meta/recipes-core/zlib/zlib_1.2.11.bb
index 6410519882d..41ec29d95e8 100644
--- a/meta/recipes-core/zlib/zlib_1.2.11.bb
+++ b/meta/recipes-core/zlib/zlib_1.2.11.bb
@@ -7,7 +7,6 @@ LICENSE = "Zlib"
LIC_FILES_CHKSUM =
"file://zlib.h;beginline=6;endline=23;md5=5377232268e952e9ef63bc555f7aa6c0"
SRC_URI = "${SOURCEFORGE_MIRROR}/libpng/${BPN}/${PV}/${BPN}-${PV}.tar.xz \
- file://remove.ldconfig.call.patch \
file://Makefile-runtests.patch \
file://ldflags-tests.patch \
file://run-ptest \
@@ -24,7 +23,7 @@ RDEPENDS_${PN}-ptest += "make"
inherit ptest
do_configure() {
- uname=GNU ./configure --prefix=${prefix} --shared --libdir=${libdir}
+ LDCONFIG=true ./configure --prefix=${prefix} --shared
--libdir=${libdir} --uname=GNU
}
do_compile() {
--
2.11.0
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] devtool sdk-update: unconditionally append updateserver to sstate mirrors
The code in sdk.py which checks if SSTATE_MIRRORS is set before
appending the updateserver to SSTATE_MIRRORS was written before
it was being set in the eSDK's local.conf (OE-Core commit
6b9e8b780dcd8d5ffba3df35cfe41674413ee26d).
Unconditionally appending updateserver to SSTATE_MIRRORS as this is
pretty safe to do.
[YOCTO #12884]
Signed-off-by: Jaewon Lee
Signed-off-by: Alejandro Enedino Hernandez Samaniego
Signed-off-by: Manjukumar Matha
---
scripts/lib/devtool/sdk.py | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/scripts/lib/devtool/sdk.py b/scripts/lib/devtool/sdk.py
index 4616753797..37f2af3f5c 100644
--- a/scripts/lib/devtool/sdk.py
+++ b/scripts/lib/devtool/sdk.py
@@ -214,10 +214,9 @@ def sdk_update(args, config, basepath, workspace):
shutil.rmtree(os.path.join(basepath, 'downloads', 'uninative'))
shutil.move(os.path.join(tmpsdk_dir, 'downloads', 'uninative'),
os.path.join(basepath, 'downloads'))
-if not sstate_mirrors:
-with open(os.path.join(conf_dir, 'site.conf'), 'a') as f:
-f.write('SCONF_VERSION = "%s"\n' % site_conf_version)
-f.write('SSTATE_MIRRORS_append = " file://.*
%s/sstate-cache/PATH \\n "\n' % updateserver)
+with open(os.path.join(conf_dir, 'site.conf'), 'a') as f:
+f.write('SCONF_VERSION = "%s"\n' % site_conf_version)
+f.write('SSTATE_MIRRORS_append = " file://.* %s/sstate-cache/PATH
\\n "\n' % updateserver)
finally:
shutil.rmtree(tmpsdk_dir)
--
2.18.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
