[Numpy-discussion] powerpc yellow dog linux port of numpy
Fri Apr 18 20:19:09 CDT 2008
I reported back on August 30 to this list,
with some discussion following on September 4 and 5,
about my attempt to build numpy on an ancient powerpc setup.
I'm running yellow dog linux 2.1, gcc 184.108.40.20610111, on processors from Curtiss-Wright Controls.
Don't tell me to just upgrade; this configuration will be
fighting the good fight for several more years.
I just retried with the latest numpy (svn yesterday) and gotten further than I did before.
umathmodule.c gets many compiler errors from gcc, of two kinds.
The simpler were like
warning: conflicting types for built-in function `sinl'
repeated for `cosl', `fabsl', and `sqrtl'.
These seem to be caused by npy_longdouble being typedef'ed as double not long double,
due to the latter two types having the same size.
umathmodule.c defines its own sinl, sqrtl, etc. with npy_longdouble arguments and results,
which then conflict with the builtin sinl, sqrtl provided by gcc that expect long double.
I worked around that by adding the "-fno-builtin" argument to the extra_compiler_args in setup.py.
The other compiler complaints from the same file were:
inconsistent operand constraints in an `asm'
which came from every line that raised a division by zero exception,
the code in each case being "feraiseexcept( FE_DIVBYZERO)" after preprocessing.
That function is defined in fenv.h with a "__THROW" attribute,
but I saw no sign of it being an inline asm or anything.
I don't understand "__THROW".
I'm afraid I would need to find the asm code involved, before I could
see what "operand constraints" are "inconsistent".
Any hints where to look?
Any way to make the call go to a nice simple library instead?
More information about the Numpy-discussion