Release candidate tool chain for 4.12

Chris Johns chrisj at
Thu Jul 27 22:28:49 UTC 2017

On 28/07/2017 00:40, Joel Sherrill wrote:
> On Thu, Jul 27, 2017 at 7:50 AM, Sebastian Huber
> <sebastian.huber at <mailto:sebastian.huber at>>
> wrote:
>     Hallo,
>     the GCC 7.2 release will be probably in two weeks. I would like to use GCC
>     7.2 and the Newlib snapshot 2017-07-20 for the RTEMS 4.12 release candidate.
>     I propose to do the 4.12 branch one week after the tool chain update.

I do not think we are ready for a branch. I think a definite plan would help
identify what we want to complete and create a focus.

> I don't mind bumping binutils and gcc. For now, that newlib snapshot is OK but I
> think we may want to bump to a newer one to catch the added POSIX methods from
> Aditya.

Agree plus we *cannot* branch until we have a build on Windows. I do not want to
have to work on a branch again to complete that task.

We also need a bit of time after an update of the tools for testing. A week is
tight for me.

> What concerns me is: which still shows
> 80 tickets and I still don't think there is one describing the x86 breakage on
> libbsd. I have no idea how many of those should be addressed. These should be
> evaluated rather than just kicked down the road.


> I did a build sweep with fresh tools yesterday. All BSPs built in my
> configuration and the warnings are in OK shape. I have filed some tickets about
> a few but most of these are very easy to fix for the right person. Here are some
> areas by person who could fix quickly. Out of 57 unique warnings:
> + 12 are in libdebugger(Chris) 

I have a patch for libdebugger I am still testing.

> + 6-8 are in BSPs or termios that I think you need to look at.
> + 7 are in new mmap code (Gedare)>
> It would be great if the core developers could take a look at the full report
> and see what can be eliminated
> There are somie warnings for the static asserts. I suspect these are due to BSPs
> are low optimization levels.
> So I would like to make sure we:
> + know the state of all tickets and consciously make a decision on them.
> + address some of these warnings.
  + Windows build of tools.
  + updated to work with repo updates and releases.
  + Zynq PCAP patches from Patrick which are on the list
  + examples-v2 building

> That doesn't begin to address whether BSPs work or odd issues like do we switch
> to Couverture for qemu.

What is the status of GSoC work? What are we looking at having merged onto master?

> I'm not trying to be an impediment. I just want a burn down list.

As you say a review of the tickets on the 4.12.0 milestone would be good. This
can then become the list of tasks we need to complete.


More information about the devel mailing list