This is the mail archive of the
newlib@sourceware.org
mailing list for the newlib project.
Re: Build failure on MIPS (strtorx.c)
- From: "Maciej W. Rozycki" <macro at imgtec dot com>
- To: Steve Ellcey <sellcey at imgtec dot com>
- Cc: <newlib at sourceware dot org>
- Date: Tue, 24 Nov 2015 18:28:16 +0000
- Subject: Re: Build failure on MIPS (strtorx.c)
- Authentication-results: sourceware.org; auth=none
- References: <6b3cf942-89f5-43f0-bb0b-33a8f1c8515a at BAMAIL02 dot ba dot imgtec dot org>
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[01234] 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.
Maciej