public inbox for java-prs@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: java-prs
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: java-prs
------- 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: java-prs
------- 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: java-prs
------- 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).