This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: tst-strtod-round.c build failure on ARM
- From: Will Newton <will dot newton at linaro dot org>
- To: libc-alpha <libc-alpha at sourceware dot org>
- Date: Fri, 12 Sep 2014 15:48:06 +0100
- Subject: Re: tst-strtod-round.c build failure on ARM
- Authentication-results: sourceware.org; auth=none
- References: <CANu=Dmj4N5FKt7bVceWowy=iG3if7VM_2ZudA-fvuy2WZEw9oQ at mail dot gmail dot com>
On 12 September 2014 12:19, Will Newton <will.newton@linaro.org> wrote:
> Hi,
>
> With today's master tst-strtod-round.c fails to build on ARM:
>
> tst-strtod-round.c: In function âtest_in_one_modeâ:
> tst-strtod-round.c:7859:7: error: implicit declaration of function
> âcopysignlâ [-Werror=implicit-function-declaration]
> || copysignl (1.0L, ld) != copysignl (1.0L, expected->ld))
> ^
> tst-strtod-round.c:7859:10: warning: incompatible implicit declaration
> of built-in function âcopysignlâ [enabled by default]
> || copysignl (1.0L, ld) != copysignl (1.0L, expected->ld))
> ^
> cc1: some warnings being treated as errors
>
> The failure is caused by the implicit function declaration now being
> treated as an error. math.h is included in tst-strtod-round.c for
> copysignl but the declaration of copysignl is guarded with the
> following conditional in math/math.h:
>
> # if !(defined __NO_LONG_DOUBLE_MATH && defined _LIBC) \
> || defined __LDBL_COMPAT
>
> On ARM __LDBL_COMPAT is not defined (I am not sure where it ever gets
> defined), but __NO_LONG_DOUBLE_MATH is and _LIBC is defined by
> libc-symbols.h, which is explicitly included on the command line by
> Makeconfig.
>
> Does anybody know what the correct fix for this would be? It seems
> strange to define _LIBC for test code but it looks like it is required
> by some tests.
Just to correct this last bit - I tried to not include libc-symbols.h
for nonlib targets, but that doesn't seem to work as some stuff in
iconv needs it (I didn't investigate very far).
> Thanks,
>
> --
> Will Newton
> Toolchain Working Group, Linaro
--
Will Newton
Toolchain Working Group, Linaro