public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
* [Bug libgcj/31662] New: Can't boostrap current gcc trunk with libjava @ 2007-04-23 2:44 davek at gcc dot gnu dot org 2007-04-24 23:53 ` [Bug libgcj/31662] " tromey at gcc dot gnu dot org ` (2 more replies) 0 siblings, 3 replies; 4+ messages in thread From: davek at gcc dot gnu dot org @ 2007-04-23 2:44 UTC (permalink / raw) To: gcc-bugs 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
* [Bug libgcj/31662] Can't boostrap current gcc trunk with libjava 2007-04-23 2:44 [Bug libgcj/31662] New: Can't boostrap current gcc trunk with libjava davek at gcc dot gnu dot org @ 2007-04-24 23:53 ` tromey at gcc dot gnu dot org 2007-04-25 0:23 ` davek at gcc dot gnu dot org 2009-07-20 1:25 ` davek at gcc dot gnu dot org 2 siblings, 0 replies; 4+ messages in thread From: tromey at gcc dot gnu dot org @ 2007-04-24 23:53 UTC (permalink / raw) To: gcc-bugs ------- 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
* [Bug libgcj/31662] Can't boostrap current gcc trunk with libjava 2007-04-23 2:44 [Bug libgcj/31662] New: Can't boostrap current gcc trunk with libjava davek at gcc dot gnu dot org 2007-04-24 23:53 ` [Bug libgcj/31662] " tromey at gcc dot gnu dot org @ 2007-04-25 0:23 ` davek at gcc dot gnu dot org 2009-07-20 1:25 ` davek at gcc dot gnu dot org 2 siblings, 0 replies; 4+ messages in thread From: davek at gcc dot gnu dot org @ 2007-04-25 0:23 UTC (permalink / raw) To: gcc-bugs ------- 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
* [Bug libgcj/31662] Can't boostrap current gcc trunk with libjava 2007-04-23 2:44 [Bug libgcj/31662] New: Can't boostrap current gcc trunk with libjava davek at gcc dot gnu dot org 2007-04-24 23:53 ` [Bug libgcj/31662] " tromey at gcc dot gnu dot org 2007-04-25 0:23 ` davek at gcc dot gnu dot org @ 2009-07-20 1:25 ` davek at gcc dot gnu dot org 2 siblings, 0 replies; 4+ messages in thread From: davek at gcc dot gnu dot org @ 2009-07-20 1:25 UTC (permalink / raw) To: gcc-bugs ------- 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2009-07-20 1:25 UTC | newest] Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2007-04-23 2:44 [Bug libgcj/31662] New: Can't boostrap current gcc trunk with libjava davek at gcc dot gnu dot org 2007-04-24 23:53 ` [Bug libgcj/31662] " tromey at gcc dot gnu dot org 2007-04-25 0:23 ` davek at gcc dot gnu dot org 2009-07-20 1:25 ` davek at gcc dot gnu dot org
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).