GCC Version Questions
chrisj at rtems.org
Sun Apr 29 01:52:51 UTC 2012
On 28/04/12 6:18 PM, Thomas Doerfler wrote:
> Am 28.04.2012 05:57, schrieb Ralf Corsepius:
>> On 04/27/2012 04:00 PM, Sebastian Huber wrote:
>>> I would rather use GCC 4.6.X for the RTEMS 4.11 release on ARM since I
>>> had a lot of trouble with earlier version of GCC 4.6. I worked with GCC
>>> 4.6 during the whole 4.11 development cycle and I am really at unease to
>>> use an untested GCC 4.7 for this release.
>> a) rtems4.11 is the unstable, rolling development branch, which may eat
>> the hair of your head and may eat your family and children.
>> It's _you_ (The developers) who are testing and are supposed to find,
>> report and occasionally fix the bugs.
> Sebastian, maybe it makes sense to give gcc-4.7 a try. we have not yet
> branched off towards a 4.11 release, so Ralfs view seems reasonable to me.
Thomas, I do not fully agree. The HEAD is the place for new development
and not suitable for production. Features and changes should be added
once they are stable, complete and tested. If you are working on changes
that can break others use your personal repo or a private repo until you
have stability. It is the developer's responsibility to track head and
merge in changes while they work on new features. There is nothing
unusual in this, just common sense. I see no reason to treat the tools
any differently. The tool are pushed out with no staging, testing,
method of review and often no announcement. The patches used to build
the tools are jumbo and it is difficult to find the relationship to a
patch and documented fix in the upstream project. I have never seen any
test reports for the tools in the yum repo.
The tools seem to follow a linear path and at best I can only describe
as some sort of Linux distribution packaging model. Why RTEMS follows
this model is a mystery to me.
RTEMS is about the RTEMS code base and not a means to trial and test
tools. It is good engineering practice to vary only one thing at a time
and not to have 2 parts varying. Currently if you are adding new
features to the RTEMS code base you also have the adding uncertainty of
the state of the tools. As the recent bintutils powerpc bug has shown it
seems the developers attempting to work on RTEMS need to clean up and
fix tool issues in order to do the work on the RTEMS code.
I see us needing stable and experimental tool chains on head and release
branches. When a tool chain has suitable test reports from the gcc test
suite and the RTEMS test suite for the effected architectures the
project should be consulted about moving that specific tool set to stable.
>> Devs are working on trunk, introducing "new stuff", breaking APIs and
>> ABIs ad-lib, but do not care about RTEMS-4.10. It's unfortunate and sad,
>> but it's the natural way.
> Surely trunk is the main line we developers think off. Anyway, relevant
> bug fixes are regularly ported back the the previous version(s) in
> RTEMS. This may even be intensified with the availability of extra
> manpower or funding ;-)
There is a lot of work in the back ground regarding 4.10 support for
those active projects using it. Stability and compatibility are the key
issues. We are sensitive and proactive to those user's who work with the
More information about the devel