Re: Build Linux: FAILED devel/qemu4 on x86_64-linux-gnu (qemu-v4.1.0-x86_64-linux-gnu-1)

2020-05-03 Thread Chris Johns
Hi Anders, Thank you for the detailed review and analysis. It helped. On 3/5/20 6:06 pm, Anders Montonen wrote: On 3 May 2020, at 8:37, Joel Sherrill > wrote: This appears to fail from the m2005 release snapshot but not when building git master. This is on CentOS 7.

Re: RSB fails to build qemu.bset

2020-05-03 Thread Chris Johns
On 3/5/20 4:33 am, Joel Sherrill wrote: On Sat, May 2, 2020, 12:42 PM Cláudio Maia > wrote: Hello everyone, I'm trying to build the toolchain for the build set devel/qemu.bset with the goal of executing RTEMS applications on top of LEON3 bsp on

Re: [PATCH rtems_waf] rtems: Add uninstall option to the list of commands

2020-05-03 Thread Chris Johns
Hi Are uninstall command useful with RTEMS? A use case that shows how it would be used may help. I use separate prefixes to manage this. We do not track common files when installing to a common prefix so building ARM and then PowerPC to the same prefix then uninstalling only the PowerPC

[PATCH rtems-libbsd] wscript: add uninstall command

2020-05-03 Thread Vijay Kumar Banerjee
--- wscript | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/wscript b/wscript index 3ca9478e..0979644a 100644 --- a/wscript +++ b/wscript @@ -151,7 +151,7 @@ def bsp_init(ctx, env, contexts): # Transform the commands to per build variant commands commands = []

[PATCH rtems_waf] rtems: Add uninstall option to the list of commands

2020-05-03 Thread Vijay Kumar Banerjee
--- rtems.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/rtems.py b/rtems.py index ceabcd9..067a213 100644 --- a/rtems.py +++ b/rtems.py @@ -131,7 +131,7 @@ def init(ctx, filters = None, version = None, long_commands = False, bsp_init = # commands = []

Fwd: Build FreeBSD: FAILED 5/bsps/beagleboneblack on x86_64-freebsd12.1 (rtems-tools-5.0.0-m2005-1-1)

2020-05-03 Thread Joel Sherrill
I'm surprised the beagle bset is failing for m2005 on FreeBSD 12.1. Ideas? -- Forwarded message - From: Date: Sun, May 3, 2020, 11:04 AM Subject: Build FreeBSD: FAILED 5/bsps/beagleboneblack on x86_64-freebsd12.1 (rtems-tools-5.0.0-m2005-1-1) To: RTEMS Source Builder - Set

Fwd: Build FreeBSD: FAILED 5/bsps/erc32 on x86_64-freebsd12.1 (rtems-tools-5.0.0-m2005-1-1)

2020-05-03 Thread Joel Sherrill
All the m2005 SPARC bsp bsets appear to be failing on FreeBSD 12.1. Anyone spot anything in this report? -- Forwarded message - From: Date: Sun, May 3, 2020, 11:57 AM Subject: Build FreeBSD: FAILED 5/bsps/erc32 on x86_64-freebsd12.1 (rtems-tools-5.0.0-m2005-1-1) To: RTEMS

Re: Different build time warnings for ticket 3908

2020-05-03 Thread Joel Sherrill
On Sun, May 3, 2020 at 7:38 AM Gedare Bloom wrote: > On Sat, May 2, 2020 at 7:18 AM Richi Dubey wrote: > > > > Hii, > > > > I know everyone is quite busy with the coming release but I'd be glad > > if someone could answer a quick question: Does the gcc version affect > > build time warnings for

Re: Different build time warnings for ticket 3908

2020-05-03 Thread Gedare Bloom
On Sat, May 2, 2020 at 7:18 AM Richi Dubey wrote: > > Hii, > > I know everyone is quite busy with the coming release but I'd be glad > if someone could answer a quick question: Does the gcc version affect > build time warnings for a bsp? > > Thanks. > > On Wed, Apr 29, 2020 at 7:56 PM Richi Dubey

Re: RSB fails to build qemu.bset

2020-05-03 Thread Cláudio Maia
On 02/05/20 19:33, Joel Sherrill wrote: > > > On Sat, May 2, 2020, 12:42 PM Cláudio Maia > wrote: > > Hello everyone, > > I'm trying to build the toolchain for the build set devel/qemu.bset with > the goal of executing RTEMS applications on top of LEON3 bsp on

Re: Build Linux: FAILED devel/qemu4 on x86_64-linux-gnu (qemu-v4.1.0-x86_64-linux-gnu-1)

2020-05-03 Thread Anders Montonen
On 3 May 2020, at 8:37, Joel Sherrill wrote: > > This appears to fail from the m2005 release snapshot but not when building > git master. This is on CentOS 7. > > Hopefully there is something useful in what was mailed out. If not, I'll dig > into the saved stuff on the machine tomorrow. >