Re: Wrong unconditional dependency on nanl

Corinna Vinschen <[email protected]>
Newsgroups gmane.comp.lib.newlib
Message-ID <[email protected]>
On Oct 10 22:25, Christophe Lyon wrote:
> On Wed, 10 Oct 2018 at 18:05, Corinna Vinschen <[email protected]> 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 <[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...?
> > >
> > > ...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
signature.asc (application/pgp-signature, 833 B)
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEoVYPmneWZnwT6kwF9TYGna5ET6AFAlu+96gACgkQ9TYGna5E
T6CVOQ//R073ok44jAtRLYPH8X4QqC+0tFBrPok8UjqgyWgYpLqffPsOYrTglYNQ
mAE7hEmiVB53vpaNDtottiRCslthDCPdzNO51LyrMTsV6b+icCrfa704sKlMvx4K
1XZ0yhIB/539UW8pJYucrpora6miBAUjzCkIIO5ZmZ5+CJFvP+apzGQfEbrS4wop
7RXXQRvSp6yewE4AJWxl/cdJligvZNxnAOSEe6OPPOol+3nYj5NsSIQTv3pSfiR0
E6XSQv1kRe3Oyb7AiaaxyKyRvC9gfVyzACGEUovme9n/EXIhd8rNx8ty2elnqslc
ar+EIx5qdETRwLJAttk5WX78Sk+X17BXiYYbXr7UthICRZ9ddL6zirCAgXgSGzSb
Jg3wK5FJ6GZvC2w1AzAMPTIRCYvsnmJKo7uueKzkJcJEFRPqwsxQnmaVTuTKo+q7
KKVzYJsk+naFl811oLppyq87DkxZ0upEn5WkIWFG1c4m2nyvGqaoz3ogia37MMwC
cU/iuh39vZc9Q3V9FB1aDSQrA0m0eU0ilYB+SJoBplO7nwqTVDmNWzceycrYjkRc
z8ZrzCHYjNNt8zYGsV1gi0EnNVCqOvqx/iWTbEbvyG9XZxJX1WLgGbuXNI88CrSE
UKmw4t1IQd2axsxjSyVTkLMdsxgyTIO+EwUmj2Phit5p5xWLTIU=
=SP1c
-----END PGP SIGNATURE-----
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.