[Numpy-discussion] Solaris Sparc build broken

David Cournapeau cournape@gmail....
Wed Nov 4 19:57:36 CST 2009


On Thu, Nov 5, 2009 at 4:55 AM, Michael Droettboom <mdroe@stsci.edu> wrote:
> David Cournapeau wrote:
>> On Thu, Nov 5, 2009 at 2:15 AM, Michael Droettboom <mdroe@stsci.edu> wrote:
>>
>>> I'm getting the following from r7603 on Solaris Sparc -- somehow related
>>> to not having a long double version of next after available.  I realise
>>> not everyone has access to (or is dependent on) this platform, so I'm
>>> willing to help in whatever way I can, I'm just not sure I understand
>>> the change yet.
>>>
>>
>> The only way to implement nextafter that I know of requires to know
>> the exact representation of the floating point number, and long double
>> is unfortunately platform dependent.
>>
>> What is the long double format on solaris sparc ? (big endian I
>> suppose, but how many bits for the mantissa and  exponent ? Does it
>> follow IEER754 ?)
>>
> I honestly don't know -- I've never had to use them.  It would be great
> to solve this properly but it's difficult to find definitive information
> about these things.
>
> Assuming we can't solve this the "right" way before the next release,
> would it be possible for this to raise a runtime "NotImplemented" error
> (by not defining the LONGDOUBLE_nextafter ufunc) rather than raising a
> compiler error which prevents the build from completing?

To be honest, I thought this condition would never arise (I am quite
surprised that solaris does not have nextafter - both BSD and GNU libc
use the Sun implementation for this function).

If this is not fixed within the code freeze (16th november), the
feature will be removed altogether for 1.4.0. I don't want to go down
the road of different feature set for different platforms.

David


More information about the NumPy-Discussion mailing list