GCC version for RTEMS 6?

[Chris Johns]

On 5/5/2022 7:15 pm, Karel Gardas wrote:
> On 5/5/22 01:32, Chris Johns wrote:
>> On 4/5/2022 8:57 pm, Sebastian Huber wrote:
>>> On 04/05/2022 09:11, Chris Johns wrote:
>>>>> I updated the RTEMS 7 tools to use the GCC 12 release branch with a gcov back
>>>>> port. You can test GCC 12 with a local patch for RTEMS 6:
>>>>>
>>>>> diff --git a/rtems/config/6/rtems-default.bset
>>>>> b/rtems/config/6/rtems-default.bset
>>>>> index 731c9d8..381f916 100644
>>>>> --- a/rtems/config/6/rtems-default.bset
>>>>> +++ b/rtems/config/6/rtems-default.bset
>>>>> @@ -15,5 +15,5 @@ devel/gmp-6.2.1
>>>>>    tools/rtems-gdb-11.2
>>>>>
>>>>>    tools/rtems-binutils-2.38
>>>>> -tools/rtems-gcc-10-newlib-head
>>>>> +tools/rtems-gcc-head-newlib-head
>>>>>    tools/rtems-tools-6
>>>> Ah ok and thanks. I will take a look and report back. It will take a couple of
>>>> days for me to work through this.
>>>
>>> Ok, thanks.
>>>
>>>>
>>>> It would be nice to be able to handle this without changing anything.
>>>
>>> I can commit this change if it helps.
>>
>> This assumes it is ok and I prefer we get posted test results before such a
>> change. Until we have this we need to wait until we all each do a level of
>> testing we are happy with. A solution that lets us test would steam line this.
>>
>> I think this is a use case where something added to the RSB may be required to
>> make this easier. For example logic in a bset file would be nice.
> 
> Your idea is excellent, but I think we also may need something more simple and
> history preserving for the time releases are already done.
> 
> Hence I sent a patch series creating config/6.1 as a preparation for 6.1 release
> with gcc 10 and update 6 (as a 6 branch dev) with Sebastian's updated GCC 12).
> 
> Just meant as material for discussion.

I understand and thank you for contributing.

A release is the tarfiles and that is fixed. In git a release is a series of
hashes or tags or both across a number of repos. The issue with this approach is
the layering of another number and interface onto the deployment so a user's
tools or scripts would need to match the version and dot to the tarball they are
using. I user will tend to just fetch the new dot point tarball and build.

I originally had the RSB as a single repo for all releases at once but it became
clear this model was never going to work and Sebastian made a case for it to be
branched in each release and kept in a linear manner on each release branch. It
was the right choice then and I believe it continues to be the right choice. I
see this change as a half step back.

Thank you for the idea and the input.

Chris