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

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

[davek 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

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

[tromey at gcc dot gnu dot org]

------- Comment #1 from tromey at gcc dot gnu dot org  2007-04-25 00:53 -------
In general I think if there is a variant in the libgcj fdlibm, then
we want to use it.
What is __cdecl for?


-- 

tromey at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tromey at gcc dot gnu dot
                   |                            |org


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

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

[davek at gcc dot gnu dot org]

------- Comment #2 from davek at gcc dot gnu dot org  2007-04-25 01:23 -------
It determines the calling convention used, and is therefore surely the
territory of the system headers/libs.  Do take a look at the upstream source:

http://sourceware.org/cgi-bin/cvsweb.cgi/src/newlib/libc/include/_ansi.h?rev=1.4&content-type=text/x-cvsweb-markup&cvsroot=src

after all, it comes from the same place mprec comes from.  Someone snipped the
#if __CYGWIN__ clause somewhere down the line.

Would you be happier with a patch that just imported that block of definitions
verbatim from newlib?  I don't think it's likely to change often and need
resyncing!


-- 


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

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

[davek at gcc dot gnu dot org]

------- Comment #3 from davek at gcc dot gnu dot org  2009-07-20 01:25 -------
Long since fixed.


-- 

davek at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |FIXED


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