Wrong unconditional dependency on nanl

[Corinna Vinschen]

On Oct 10 22:25, Christophe Lyon wrote:
> On Wed, 10 Oct 2018 at 18:05, Corinna Vinschen <vinschen@redhat.com> wrote:
> >
> > On Oct 10 17:36, Corinna Vinschen wrote:
> > > On Oct 10 17:31, Corinna Vinschen wrote:
> > > > On Oct 10 11:22, Craig Howland wrote:
> > > > > On 10/10/2018 10:52 AM, Corinna Vinschen wrote:
> > > > > > On Oct 10 15:48, Christophe Lyon wrote:
> > > > > > > On Wed, 10 Oct 2018 at 11:41, Corinna Vinschen <vinschen@redhat.com> wrote:
> > > > > > > > On Oct  8 15:06, Christophe Lyon wrote:
> > > > > > > >
> > > > > > > It does help on aarch64-elf, but a change to rdimon.specs is required
> > > > > > > because libc now depends on libm: this can be seen when compiling a
> > > > > > > C++ hello.cpp.
> > > > > > Hmm, that's an interesting point.  What I don't understand is why this
> > > > > > dependency wasn't already visible before.  strtod.c and wcstod.c call
> > > > > > nan() and nanf(), vfprintf.c and vfwprintf.c call nanf().  Why is a
> > > > > > call to nanl() different?
> > > > > The nanl() call was only added perhaps a few weeks ago.  At that time we
> > > > > missed the thought that it comes from libm.  We'd need to add it to
> > > > > newlib/Makefile to be copied like s_nan and sf_nan presently are.
> > > >
> > > > Yeah, just found this myself.  nan/nanf are pulled in via newlib's
> > > > top-level Makefile.am:
> > > >
> > > >   MATHOBJS_IN_LIBC = ...
> > > >
> > > > Pulling in nanl is a problem because it's build depends on
> > > > HAVE_LONG_DOUBLE.
> > > >
> > > > Maybe we should really just use __builtin_nanl in strtorx.c...?
> > >
> > > ...and build strtorx.c only if HAVE_LONG_DOUBLE, just like strtold.c and
> > > wcstold.c.
> >
> > I pushed three patches to handle all of the above.  Please give them
> > a try.
> >
> I confirm it works for me on aarch64.
> Thanks!

Thanks for testing.


Corinna

-- 
Corinna Vinschen
Cygwin Maintainer
Red Hat
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/newlib/attachments/20181011/70fad7c3/attachment.sig>