This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Link tests after GCC_NO_EXECUTABLES
On Fri, Nov 30, 2007 at 08:44:59AM +0000, Richard Sandiford wrote:
> Rask Ingemann Lambertsen <rask@sygehus.dk> 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 <dj@redhat.com>
>
> * 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