Re: Wrong unconditional dependency on nanl

On 10/10/2018 11:31 AM, 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...?
>
>
> Corinna
>
I had actually sent this as a suggestion a couple of days ago, but somehow my 
email didn't make it to the list.  Here's the whole thing I sent, even though 
the two numbered points have since been realized and discussed:

I think the problem is probably two-fold.
1)  nanl() is in the math library, so -lm would be needed when linking.
2)  As you think, nanl() is only defined when LDBL_EQ_DBL.
I suggest that a workaround is to replace 'nanl("")' with '__builtin_nanl("")'.  
It is somewhat ugly, but it would be better than what it is now (it has the 
major advantage of getting around the -lm problem), and arguably no worse.  
While strictly it would need something like "#if __GNUC_PREREQ (3, 3)" to go 
with it, not doing so could just fail at link time like it is presently.

As Corrina had noted, it seems pretty unlikely that anyone is older than GCC 3.3 
at this point.
Craig