report attached was Re: embedded target status on main CVS trunk

[Joel Sherrill <joel dot sherrill at OARcorp dot com>]

Daniel Jacobowitz wrote:
> 
> On Mon, Feb 11, 2002 at 02:19:52PM -0600, Joel Sherrill wrote:
> >
> > Hi,
> >
> > I was asked to repeat my test on the main trunk.  Sadly it appears
> > to be even worse than the 3.0-branch.
> >
> > The details are in the attached file but basically I attempted to
> > build 34 cross targets on a RedHat 7.2 box using mainline CVS
> > GCC source and report the results.
> 
> There wasn't an attachment...

Sorry.  It is easy to forget. :(

One thing I noticed is that a number of targets that at least configured
with gcc 3.0, simply failed to configure successfully and claimed not
to be supported -- h8300-coff, h8300-rtems, and i386-elf among them.

> > FWIW when the toolset builds complete, I can run the gcc test suite
> > on many of the targets.  Should I fix my script to automatically mail
> > in test results?  Would this be too much noise on the testresults
> > list?
> >
> > Thanks.
> >
> > --
> > Joel Sherrill, Ph.D.             Director of Research & Development
> > joel@OARcorp.com                 On-Line Applications Research
> > Ask me about RTEMS: a free RTOS  Huntsville AL 35805
> >    Support Available             (256) 722-9985
> >
> 
> --
> Daniel Jacobowitz                           Carnegie Mellon University
> MontaVista Software                         Debian GNU/Linux Developer

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel@OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
   Support Available             (256) 722-9985
Hi,

I have checked out the gcc 3.0 branch and built a number of cross-targets
using a RedHat 7.2 host, newlib 1.10.0 w/minimal patches, and 
binutils 2.11.2.  I have run the test suites but am not reporting
those at this time.  I would really like to get feedback on how 
people feel about letting a script email the results.  Would
this cause overload?

At this time this is just build results for C/C++ at this point.

There are few outstanding patches which need to be submitted to
get to this point:

  + newlib 1.10.0 - does not build setjmp/longjmp for i386-* targets
  + newlib 1.10.0 - libgloss/dummy.? does not agree on mem_err definition
                  - m68k-coff has known libgloss linking problems 
  + gcc           - misc RTEMS patches and one to sparc-elf to fix 
                    re-assert of cpu and machine

Here are the results

arc-elf 	- PR3587 
arm-elf		- BUILDS
arm-rtems	- BUILDS 
avr-elf		- PR3931
d30v-elf	- configure fails as not supported in gcc 
fr30-elf	- configure fails as not supported in gcc
h8300-coff	- configure fails as not supported in gcc
h8300-rtems	- configure fails as not supported in gcc
hppa1.1-proelf	- configure fails as not supported in gcc
i386-elf	- configure fails as not supported in gcc (i386-pc-elf)
i386-rtems	- ICE for libgcc2.c:1061 in extract_insn at recog.c:2129
i960-coff	- BUILDS
i960-elf	- libgloss sections attributes not supported for this target
i960-rtems	- BUILDS
m32r-elf	- BUILDS
m68k-coff	- fails configure in libgloss
m68k-elf	- BUILDS
m68k-rtems	- BUILDS
mcore-elf	- PR3591
mips64orion-elf	- BUILDS
mips64orion-rtems - BUILDS
mips-elf	- BUILDS
mips-rtems	- BUILDS
mn10200-elf	- similar failure as i386-rtems
mn10300-elf	- BUILDS
powerpc-eabi	- Relocation cannot be done when using -mrelocatable
powerpc-elf	- Relocation cannot be done when using -mrelocatable 
powerpc-rtems	- Relocation cannot be done when using -mrelocatable
sh-coff		- binutils 2.11.2 tc-sh.c:3353 abort on BFD_RELOC_32 error
sh-elf		- Illegal assemble compiling crtbegin.S (1st char is -)
sh-rtems	- binutils 2.11.2 tc-sh.c:3353 abort on BFD_RELOC_32 error
sparc-elf	- fails building _trampoline.c, need prototypes for
		  getpagesize(), mprotect(), and perror().
sparc-rtems	- same as sparc-elf
v850-elf	- segfault compiling regex.c:4309