[rtems-crossrpms commit] Reflect arm-rtems being history.
chrisj at rtems.org
Mon Apr 30 01:08:14 UTC 2012
[ will answer in this thread ]
On 30/04/12 3:03 AM, Thomas Doerfler wrote:
> Joel, Ralf,
> when looking at GCC4.7 documentation
> there is a list of obsoleted ARM target with their supported alternatives:
> The obsolete ports with alternatives are:
> arm*-*-rtems (use arm*-*-rtemseabi)
> arm*-*-linux-gnu (use arm*-*-linux-gnueabi)
> arm*-*-elf (use arm*-*-eabi)
> arm*-*-uclinux* (use arm*-*-uclinux*eabi)
> When looking at the "linux-gnu" and "uclinux" versions which did not
> specify a special ABI or object format, gcc obviously prefers to have
> the term "eabi" in the new target name.
We have had arm support for a long time and an OS. We fit the same
pattern and there seems no reason to change. It is good you have
established this. We are not asking for a new target name.
> Joel, this is not what we defined for the ARM toolset transition,
It was my understanding. I also thought the new ABI on a different name
was temporary and not permanent. It was a mistake to even let this
happen and at the time we all just wanted to get something happening and
this seemed better than nothing at all. There is a lesson in this, not
to let it happen again.
> but we
> decided to follow GCC with the ABI transition, so I think it makes sense
> to also stick to their naming convention.
No it does not. Introduction of different naming across architectures
effects user complexity, adds confusion, effects documentation and other
flow on effects inside and outside the project . There is more to
this than the rather small patch to gcc or what the RTEMS developers see.
> What's the real problem with the naming?
There is no need to change and every reason to maintain naming
compatibility across all architectures etc. The RTEMS standard has
always been the architecture name should always default to the format,
ABI and what-ever else in the tools. There have been many cases of
format and ABI changes in gcc that have been incompatible and we have
not changed names. There is not reason to establish a precedent now and
More information about the devel