On 02/04/2014 04:13 PM, Sebastian Huber wrote:
Hello,
we have to define the tool chain versions intended for RTEMS 4.11.
For Binutils I would like to use release 2.24 with the attached patch.
For GCC we should use a recent 4.8 branch snapshot (e.g.
ftp://ftp.gwdg.de/pub/misc/gcc/snapshots/4.8-20140130/gcc-4.8-20140130.tar.bz2)
and use GCC 4.8.3 for the release. This gives us also some time to test
the RTEMS 4.11 branch, which we should create soon.
In the GCC 4.8.2 release there are several SPARC specific patches not
included which are part of the GCC 4.8 branch. We should submit all
outstanding GCC patches upstream before the GCC 4.8.3 release.
This GCC patch change is still open:
http://www.rtems.org/pipermail/rtems-devel/2013-April/002868.html
See also:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47111
Well, IMO, this is a general rtems-independent bug in the mips port.
When trying to have it fixed in GCC, some years ago, the mips
maintainers refused to apply it.
So, one may undef it for rtems as a work-around, but this is just
playing with symptoms and with a cure to the cause.
This is also an open issue:
http://www.rtems.org/pipermail/rtems-devel/2013-April/002830.html
Right, these patches should be upstreamed.
For Newlib I would use 2.1.0 without any patches or a recent snapshot.
My trust in newlib-2.x is fairly low, because of the amount of changes
it has seen and because it still has not stabilized enough to allow
proper testing.
Finally, FYI: Some weeks ago I attempted a stab on porting the
rtems-tools chains to x86_64-cygwin, but was badly hit by what I
currently assume to be a bug in cyginw's newlib-2.0, which seems to
originate from one of these changes. However, I am not sure about it, yet.
Ralf
_______________________________________________
rtems-devel mailing list
rtems-devel@rtems.org
http://www.rtems.org/mailman/listinfo/rtems-devel
