Re: [cygwin] Can't boostrap current gcc trunk with libjava: ../../../gcc/libjava/classpath/native/fdlibm/mprec.h:297:1: error: "_EXFUN" redefined

["Charles Wilson" <libtool at cwilson dot fastmail dot fm>]

Tom Tromey wrote:
> That is new to me, but then I don't build on Cygwin.
> Where does /usr/include/_ansi.h come from?
> 
> Anyway, try adding a "#undef _EXFUN" in the appropriate place in
> mprec.h.  If that works for you, send it to me and I will check it in.

Are you sure forcibly redefining _EXFUN (#undef + #define) is the right
thing?  Cygwin's (actually newlib's) /usr/include/_ansi.h does this:

#ifdef __CYGWIN__
#define _EXFUN(name, proto)             __cdecl name proto
#define _EXPARM(name, proto)            (* __cdecl name) proto
#else
#define _EXFUN(name, proto)             name proto
#define _EXPARM(name, proto)            (* name) proto
#endif

because _EXFUN symbols in the (newlib-originated, cygwin1.dll-supplied)
runtime are, in fact, __cdecl and not stdcall or fastcall.  So if the
user used -mrtd to switch the compiler's default calling convention,
symbols imported from cygwin1.dll and declared via the newlib headers
will still use the correct cdecl convention.

Unless, of course, somebody redefines _EXFUN...

Perhaps mprec.h should do something like the above (e.g. special case
for __CYGWIN__, retaining the __cdecl) rather than forcibly changing the
definition of the _EXFUN macro.  Redefining something to an identical
definition is not an error, right?  Next question: is it truly okay to
force EXFUN's in libjava to __cdecl?

Or <shudder>, should libjava avoid the reserved name '_EXFUN' for its
macro, and use some other macro for this purpose?

--
Chuck