Re: newlib and long-double question

["N. C." <necrocowmoo@gmail.com>]

On 4/10/11, Tim Prince wrote:
> On 4/10/2011 4:28 AM, Sisyphus wrote:
>>
>> ----- Original Message ----- From: "Hugh Myers"
>>
>>> The OP is trying to build Perl itself, not use it; hence the need for
>>> long double support functions...
>>
>> You don't need "long double support functions" to build perl ... unless
>> you want to build a perl whose NV is a long double (instead of a double).
>>
>> Presumably the op wants to build a perl whose NV is a long double so
>> that he can make use of that extra precision. Given that he can't build
>> such a perl, the next best way of accessing that extra precision he
>> wants is, imo, to use Math::MPFR.
>>
> I never did see a clear description of OP's goals.  "Performance" was
> among them, so it was unclear why typical mathlinline.h content would
> have been rejected e.g.
>
> __inline_mathcode_ (long double, __sqrtl, __x, return __builtin_sqrtl (__x))
>
>
> As OP indicated, the functions might not have been difficult to write,
> perhaps not as difficult as settling requirements. If the requirement
> was for sqrtl to perform faster than sqrt, the expectation was misguided.

What I wanted was merely to be able to build Perl with both the
'use64bitint' option (which appears to work), as well as the
'uselongdouble', which fails to the lack of those functions being
defined.

With Perl, I really prefer to get as close to a genuine build as
possible so as to avoid any unforeseen issues, but if you have a
suggestion to allow Perl to build with those options, I'm all ears to
hear it. That said, I still think it's overall more benefictial to
actually have those functions implimented in the spected place, within
the c library (usually in libm.)


Thank you.

N. C.

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple