GCC Version Questions

[Chris Johns]

On 28/04/12 6:18 PM, Thomas Doerfler wrote:
> Hi,
>
> 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.
>>
>> Sebastian,
>>
>> 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 
development team.

Chris