This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: newlib and long-double question

Exactly, I really need to be able to build Perl whose NV is a long
double. And this was just one example that I gave. I honestly think it
is worth it to have long double support in cygwin (to have those
functions that are currently undefined), as it seems more and more
clear that A) there is a use for them, and B) there are cases where it
really is needed.

IIRC, the whole point of cygwin is to have a unix-like environment
within a non-unix-like system, right? Does it not make sense to make
the back bone (libc) that much mroe complete, furthur augmenting
usability and compatibility?

Again, thanks to all of you for your time and input.

- N.C.

On 4/10/11, Hugh Myers wrote:
> The OP is trying to build Perl itself, not use it; hence the need for
> long double support functions...
> --hsm
> On Sun, Apr 10, 2011 at 4:25 AM, Sisyphus <> wrote:
>> ----- Original Message ----- From: "marco atzeri"
>>>> On a Linux system that I have access to, I see that those functions
>>>> are in /lib/libm.* but cygwin's /lib/libm.* still seems to lack them.
>>>> Is there any work around or alternate version ofthis lib that actually
>>>> has these functions. I honestly do not mean to be rude, but how
>>>> difficult is it to impliment these functions which seem so common in
>>>> most unix-like systems?
>>> It is not overcomplicated to implement it, but it takes time and
>>> someone to do it.
>>> When I implemented all the complex functions (cabs, ccos..) I spent one
>>> month
>>> to make it right. A more capable guy will take less surely, but as
>>> mention I see little
>>> benefit moving from 64 to 80 bits so I was not interested to implement
>>> it.
>> I sense an opportunity here to plug (to the op) the Math::MPFR perl module
>> -
>> for which the gmp and mpfr C libraries are required.
>> I guess one could also use Math::BigFloat, but I assume the op has already
>> considered (and rejected) that option - the performance hit incurred by
>> its
>> use has always discouraged me.
>> Perhaps he has also already considered and rejected Math::MPFR, but it
>> seems
>> to me to be by far the best option for achieving added precision with
>> floating point numbers - at least until such time as building perl with
>> -Duselongdouble has been facilitated.
>> Cheers,
>> Rob

Problem reports:
Unsubscribe info:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]