Tool chain for RTEMS 4.11
cynt6007 at vandals.uidaho.edu
Tue Jul 16 15:34:27 UTC 2013
I agree. We need to agree on toolchain versions before rolling out with a release, and we really want as many patches as feasible upstreamed as soon as feasible (to maximize the probability they will be commited) and, where feasible, we want toolchains for the targets to be up-to-date as well.
I know in the past some of the targets require special versions, so for the targets that still have problems during the feature freeze, we'll have to adjust for needing special toolchain versions. So I would like to propose before settling on which version to use for a given target, we verify the current toolchain version works... and if not, we make a determination of the most current version that does work.
Moving forward we should keep patches separated in such a way as they are easier to "upstream", this will require an update to the http://www.rtems.org/wiki/index.php/Building_Tools tutorial, but hopefully, updating the tutorial won't be too difficult.
We really do want just one set of patches, as opposed to having rpms and rtems-tools (and that all pathces out for users have been submitted for upstreaming)...
I also would like to propose we set a TENTATIVE feature freeze for the RTEMS kernel of Mid-October, through Mid-November -- if we integrate Summer of Code contibutions as we go, this will be enough time to integrate the features before we freeze them... then we could schedule the release to happen before contributions pick up over the holidays... with Mid-November as the TENTATIVE release date... this would also increase the probability that the tool chain patches we have now will be in the upcoming releases of the tools. This would mean features could be added until Mid-October...
From: rtems-devel-bounces at rtems.org [rtems-devel-bounces at rtems.org] on behalf of Sebastian Huber [sebastian.huber at embedded-brains.de]
Sent: Tuesday, July 16, 2013 5:11 AM
Subject: Tool chain for RTEMS 4.11
before we release RTEMS 4.11 we have to agree on the tool chain versions
(Binutils, GCC, Newlib, GDB). Currently the RTEMS developers are a bit divided
with respect to the tool chain in use. We have the RTEMS source builder based
versions and we have the RPM based ones.
The RPM based ones use patches which can be found here:
The Newlib patch is quite huge and an explanation for it can be found here:
I propose the following actions:
1. Submit all RTEMS tool chain patches for review to the rtems-devel list. The
time frame for this should be two weeks.
2. After review (after two weeks without response assume that the patch is all
right) submit the patches for upstream integration. Patches from people
without a FSF copyright assignment are problematic here.
3. After all patches are integrated upstream select an upstream snapshot
version for the RTEMS tool chain release candidate.
4. Propagate the changes to the developers.
5. Adjust the RTEMS sources accordingly.
Sebastian Huber, embedded brains GmbH
Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail : sebastian.huber at embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
rtems-devel mailing list
rtems-devel at rtems.org
More information about the devel