[Numpy-discussion] Solaris Sparc build broken

Michael Droettboom mdroe@stsci....
Tue Nov 10 15:18:07 CST 2009

I don't know if your 'long double' detection code is complete yet, but I 
thought I'd share the current build output on one of our Solaris 
machines.  It looks like it may just be a typo difference between 
'IEEE_QUAD_BE' in long_double_representation() and 'IEEE_QUAD_16B_BE' in 
setup.py, but I wanted to confirm.

 > uname -a
SunOS grail.stsci.edu 5.8 Generic_117350-62 sun4u sparc SUNW,Ultra-5_10

compile options: '-Inumpy/core/src/private -Inumpy/core/src -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray -Inumpy/core/src/umath -Inumpy/core/include -I/usr/stsci/pyssgdev/Python-2.5.4/include/python2.5 -c'

cc: _configtest.c
removing: _configtest.c _configtest.o
Traceback (most recent call last):
  File "setup.py", line 187, in <module>
  File "setup.py", line 180, in setup_package
    configuration=configuration )
  File "/grail/data1/iraf/work/build.grail.numpy.iraf/numpy/numpy/distutils/core.py", line 186, in setup
    return old_setup(**new_attr)
  File "/usr/stsci/pyssgdev/Python-2.5.4/lib/python2.5/distutils/core.py", line 151, in setup
  File "/usr/stsci/pyssgdev/Python-2.5.4/lib/python2.5/distutils/dist.py", line 974, in run_commands
  File "/usr/stsci/pyssgdev/Python-2.5.4/lib/python2.5/distutils/dist.py", line 994, in run_command
  File "/grail/data1/iraf/work/build.grail.numpy.iraf/numpy/numpy/distutils/command/install.py", line 52, in run
    r = old_install.run(self)
  File "/usr/stsci/pyssgdev/Python-2.5.4/lib/python2.5/distutils/command/install.py", line 506, in run
  File "/usr/stsci/pyssgdev/Python-2.5.4/lib/python2.5/distutils/cmd.py", line 333, in run_command
  File "/usr/stsci/pyssgdev/Python-2.5.4/lib/python2.5/distutils/dist.py", line 994, in run_command
  File "/grail/data1/iraf/work/build.grail.numpy.iraf/numpy/numpy/distutils/command/build.py", line 37, in run
  File "/usr/stsci/pyssgdev/Python-2.5.4/lib/python2.5/distutils/command/build.py", line 112, in run
  File "/usr/stsci/pyssgdev/Python-2.5.4/lib/python2.5/distutils/cmd.py", line 333, in run_command
  File "/usr/stsci/pyssgdev/Python-2.5.4/lib/python2.5/distutils/dist.py", line 994, in run_command
  File "/grail/data1/iraf/work/build.grail.numpy.iraf/numpy/numpy/distutils/command/build_src.py", line 152, in run
  File "/grail/data1/iraf/work/build.grail.numpy.iraf/numpy/numpy/distutils/command/build_src.py", line 169, in build_sources
  File "/grail/data1/iraf/work/build.grail.numpy.iraf/numpy/numpy/distutils/command/build_src.py", line 328, in build_extension_sources
    sources = self.generate_sources(sources, ext)
  File "/grail/data1/iraf/work/build.grail.numpy.iraf/numpy/numpy/distutils/command/build_src.py", line 385, in generate_sources
    source = func(extension, build_dir)
  File "numpy/core/setup.py", line 425, in generate_config_h
    raise ValueError("Unrecognized long double format: %s" % rep)
ValueError: Unrecognized long double format: IEEE_QUAD_BE

David Cournapeau wrote:
> 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
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion

Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

More information about the NumPy-Discussion mailing list