Building RSB (RTEMS Source Builder) on Windows 10

Joel Sherrill joel at
Thu Nov 16 03:36:23 UTC 2017

On Wed, Nov 15, 2017 at 4:35 PM, Chris Johns <chrisj at> wrote:

> On 16/11/2017 08:37, Jacob Saina wrote:
> > Thanks, I'm much better than I was yesterday.
> >
> Good to hear.
> > I attempted a build of the 4.11.0 release of RSB from here
> > ( on the same
> Windows 10
> > machine using the --without-rtems flag, and I get a build failure on the
> same
> > thing, after 30 minutes:
> >  Build: error: building arg4n2xwm1
> > I am attaching the error report from yesterday building 4.11.2, as well
> as
> > today's from 4.11.0.
> Please use 4.11.2, 4.11.0 is known to be broken.
> My build got lost, Windows 10 decided to update and restart over night even
> after attempting to configure it not too.

FWIW I had a sparc build go ok for the master on Windows but tried a powerpc
build and it failed with something about unable to fork. I am restarting it
letting it run again.

> > A clarification regarding the older Windows machine that was able to
> build
> > 4.11.0 -- I learned that that was using git, and checking out the 4.11.0
> tag, as
> > opposed to downloading the release tarball. Maybe that is relevant.
> I think 4.11.0 is not worth any effort and 4.11.2 is. Anything we find on
> 4.11.2
> can be put on the 4.11 branch and 4.11.3 can be released. I am starting to
> look
> at what is needed for 4.11.3.
> I have been considering the default of building the RTEMS kernel when
> building
> the tools as a result of what you have been reporting so thank you for
> taking
> the time to do this.
> In theory it is a good idea however some archs have too many BSP and the
> time
> and resources it consumes makes this problematic. It may be simpler to not
> build
> the RTEMS kernel and to make sure the documentation and Quick Start in the
> release details how to build the kernel. This way the tools get built and
> installed as a step and then the kernel can be built as a second step. At
> the
> moment any failure means no tools and kernel and that is not great or user
> friendly.

I think building RTEMS by default is a bad idea for a few reasons.

+ First, you are building everything which takes a long time and a lot of
disk space.
It is common to run out of disk space while building BSPs you don't care
I am teaching a class this week and at least one person ran during the RSB
and another forgot --enable-rtemsbsp and ran out building RTEMS. It also
took a
long time.

+ Second, it may not be the configuration the end user wants even if the BSP
they want is in the list.

+ Finally, if they are going to develop a new or work on an existing custom
BSP, then they are interested in building none of the existing BSPs in the

I just don't see the need to build all the BSPs when you build the tools.

> > Additionally, I have trouble finding these pages to download releases
> from, like
> > the one linked above, as they seem not to show up in search engine
> results. I
> > always find pages like this (
> What's
> > the typical way of navigating to them?
> Wiki's are hard to maintain and things have been moving around lots.
> In an attempt to make a single simple place to handle this I have added to
> the
> top page of the Wiki a Releases table. A click on a bookmark to the wiki
> brings
> you to this table and it is at the top so it should always be visible
> without
> scrolling.
> The table contains the releases the RTEMS project publicly supports.
> Currently
> this is 5, 4.11 and 4.10. The project supports the development branch (git
> master) and the previous two releases. Other releases may have work done
> on them
> based on commercial support efforts.
> The table contains a Download column and clicking on that link should take
> you
> to the download directory for the release. This is a second click.
> There is also a link to the Documentation and a link to create a bug for
> that
> release. Each a click from the top of the wiki page.
> The first column takes you to the Release Notes page which is a top level
> wrapper for the dot point release notes. The dot point release notes are
> captured in a PDF by the release process and placed in the release
> directory.
> I hope this helps.


If there repeatable problems against the last releases on any active
release branch, please file tickets and let us know.


> Chris
> _______________________________________________
> users mailing list
> users at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the users mailing list