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-----