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 overr
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
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/re
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
> followi
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 produc
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
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).
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 imp
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 ot
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 cand
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 --gi
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 l
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 Co
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 ++
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
> -
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, 2
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}"
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’
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 emp
> > 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 up
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-cor
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 f
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,
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 armv
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
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-
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
pr
27 matches
Mail list logo
