Build failure on MIPS (strtorx.c) [Patch attached]
Tue Nov 24 21:51:00 GMT 2015
On Tue, 2015-11-24 at 18:28 +0000, Maciej W. Rozycki wrote:
> On Mon, 23 Nov 2015, Steve Ellcey wrote:
> > The recent changes to strtorx.c and strtodg.c seem to have broken the
> > MIPS newlib build. My build is currently failing while compiling strtorx.c.
> > It complains that ldus_QNAN are undeclared and that the use of
> > _strtodg_r is an implicit function reference.
> These macros are for the x86 80-bit extended format (with an explicit
> leading significand bit). They are irrelevant for the MIPS target.
> > I am not sure what the correct fix for this is. I see the definitions
> > of ldus_QNAN* in newlib/libc/stdlib/gd_qnan.h and that it is ifdef'ed
> > for MIPS. It looks like if __mips is defined then none of the ldus_QNAN
> > macros are defined but I don't know if they should be defined or if the
> > uses of them in strtorx.c should be ifdef'ed out for MIPS.
> The `long double' type is an alias to the `double' type on MIPS/Newlib
> targets I believe, and the x86 80-bit extended format is not used so I
> think _LDBL_EQ_DBL is supposed to be defined and strtorx.c excluded from
> the build if this is the case. I can see this is already the case for the
> relevant prototypes provided in newlib/libc/stdlib/mprec.h so it looks
> like a simple bug in importing the changes in commit fbace816.
That makes sense now, I applied this patch to my local sources and was
able to build correctly again. Can someone approve this patch for
2015-11-24 Steve Ellcey <email@example.com>
* libc/stdlib/strtorx.c: Fix ifdef to check _LDBL_EQ_DBL.
diff --git a/newlib/libc/stdlib/strtorx.c b/newlib/libc/stdlib/strtorx.c
index 85d8722..44f3db2 100644
@@ -37,7 +37,7 @@ THIS SOFTWARE.
+#if defined (_HAVE_LONG_DOUBLE) && !defined (_LDBL_EQ_DBL)
@@ -126,4 +126,4 @@ _strtorx_r(struct _reent *p, const char *s, char
**sp, int rounding, void *L)
-#endif /* _HAVE_LONG_DOUBLE */
+#endif /* _HAVE_LONG_DOUBLE && !_LDBL_EQ_DBL */
More information about the Newlib