Re: Wrong unconditional dependency on nanl

Corinna Vinschen <[email protected]> Wed, 10 Oct 2018 17:31:55 +0200

Newsgroups	gmane.comp.lib.newlib
Message-ID	<[email protected]>

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 <[email protected]> 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...?


Corinna

-- 
Corinna Vinschen
Cygwin Maintainer
Red Hat

signature.asc (application/pgp-signature, 833 B)