[Bug libgcj/31662] New: Can't boostrap current gcc trunk with libjava

["davek at gcc dot gnu dot org" <gcc-bugzilla at gcc dot gnu dot org>]

Originally reported at http://gcc.gnu.org/ml/gcc/2007-04/msg00539.html,
bootstrap fails with a redefinition error for the macro _EXFUN.

In file included from ../../../gcc/libjava/classpath/native/fdlibm/fdlibm.h:29,
                from ../../../gcc/libjava/java/lang/natVMDouble.cc:27:
../../../gcc/libjava/classpath/native/fdlibm/mprec.h:297:1: error:
"_EXFUN" redefined
In file included from /usr/include/stdlib.h:10,
                from ../../../gcc/libjava/java/lang/natVMDouble.cc:14:
/usr/include/_ansi.h:36:1: error: this is the location of the previous
definition
make[3]: *** [java/lang/natVMDouble.lo] Error 1

  The problem is that cygwin (and presumably other newlib-based targets) supply
the _ansi.h compatibility header from newlib's include dir as a system header.
This defines _EXFUN and a number of other K'n'R-vs-C89 compatibility macros.

  When mprec.h was imported (from newlib, possibly indirectly via the classpath
project) it was necessary to supply equivalents to these macros that would
allow it to build on a non-newlib system.  This decision makes sense because
removing the macros and ANSI-fying the source would make future imports/merges
very tricky.  However, it leads to the redefinition problem on newlib targets
mentioned above.

  I am testing a patch that wraps the compatibility definitions in mprec.h in
#ifndef.  This is preferable to #undef'ing them, as it defers to the system's
own definitions (in cygwin's case, this include the __cdecl declarator).


-- 
           Summary: Can't boostrap current gcc trunk with libjava
           Product: gcc
           Version: 4.3.0
            Status: UNCONFIRMED
          Keywords: build
          Severity: normal
          Priority: P3
         Component: libgcj
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: davek at gcc dot gnu dot org
 GCC build triplet: i686-pc-cygwin
  GCC host triplet: i686-pc-cygwin
GCC target triplet: i686-pc-cygwin


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31662