On Fri, Nov 30, 2007 at 08:44:59AM +0000, Richard Sandiford wrote: > Rask Ingemann Lambertsen <[EMAIL PROTECTED]> writes: > > On Thu, Nov 29, 2007 at 10:05:54PM +0000, Richard Sandiford wrote: > >> It sounds like we've agreed that, if we want > >> to support libgfortran on targets like mips*-elf*, we should use > >> libstd++-like with_newlib checks there too. > > > > Likewise for the other target libraries - how many did you test? > > C, C++ and Objective C. Libjava isn't supported before or after > the patch for mips*-elf*. Which other libraries were you thinking of?
Libjava, libssp and libffi, of which libssp has already been taken care of. I checked my build directories and it looks like we only build libjava on the ARM and there, it doesn't quite build yet, but that is work in (slow) progress: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31325 http://gcc.gnu.org/svn/gcc/branches/gcj/gcj-eabi-branch/ http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32340 The only target I know of that builds libffi is ia64-unknown-elf, but expect arm-unknown-{eabi,elf} to follow. Checking ia64's libffi/config.log, I spotted three link tests (for mmap, memcpy and alloca). > I was thinking I should return it to the pre-patch situation, as I wasn't > comfortable overriding a decision made by the m32c maintainer. That said, > the changelog says: > > 2006-04-18 DJ Delorie <[EMAIL PROTECTED]> > > * configure.in (m32c): Build libstdc++-v3. Pass flags to > reference libgloss so that libssp can be built in a combined > tree. > * configure: Regenerate. > > and libssp was later made newlib-friendly by (at least): And we don't build libjava or libffi on the m32c. That leaves libgfortran which doesn't build due to PR 32055. So although that hunk did make it into the 4.2 branch, there's no loss on the m32c. -- Rask Ingemann Lambertsen Danish law requires addresses in e-mail to be logged and stored for a year
