I have to start by saying the RTEMS Project didn't manage the transition from "ARM ELF" to "ARM EABI"  as well as we have managed similar changes in the past. 
The crux of the issue is that the preferred RTEMS tool target is ALWAYS
CPU-rtems<version>. We have transitioned from a.out -> coff -> elf in the past
and always followed the same target renaming pattern.

1) provide alternative for old target CPU-rtemsOLD where
    OLD is aout, coff, elf, etc.
      - CPU-rtems stays tied to old
2) provide new target at CPU-rtemsNEW where new is
    aout, coff, elf, eabi, etc
3) verify RTEMS builds and no obvious issues with NEW.
    test what can be tested internally.
4) limited (1-2 week) open period for feedback and outside
    testing
5) if no feedback/bugs, switch CPU-rtems to CPU-rtemsNEW
    leaving CPU-rtemsOLD around as a backup 

Using CPU-rtems* makes our build instructions and use very consistent across the 15 or so architectures, RTEMS runs on.

This time, we missed something somewhere along the way and arm-rtems* got on the obsolete list and arm-rtemseabi* became the preferred target name. That breaks a very long standing and well documented pattern.

Myself and Sebastian Huber wrote and he tested these patches.  From http://www.rtems.org/pipermail/rtems-devel/2012-May/001001.html


	o the target arm-rtemseabi4.11 should be renamed to arm-rtems4.11
	  providing the up to date ARM EABI version 5 tool chain,
	o the target arm-rtemself4.11 provides the obsolete GNU EABI (also
	  known as ARM ELF) variant.

The patches for 4.6, 4.7, and the head are attached. We didn't remove the "ARM ELF" rtems target at this point. That is left for removal when general gcc clean up catches it.

GCC test suite results for arm-rtems4.11:

http://gcc.gnu.org/ml/gcc-testresults/2012-05/msg00322.html
http://gcc.gnu.org/ml/gcc-testresults/2012-05/msg00323.html
http://gcc.gnu.org/ml/gcc-testresults/2012-05/msg00324.html