On Wed, 2003-10-01 at 04:39, Jochen Küpper wrote:
Some observations:
In addons.py I found the following statement: ,---- | # Set to 0 if you have your own platform optimized BLAS and LAPACK. | # When I tried this under RH8.0 i386 Linux, there was at least one | # unresolved symbol. `----
It was my comment...
Which symbol was that?
I didn't remember then and certainly don't now. I was trying to brace the reader for the possibility that "optimized library activation" might need further work.
It seems to work for me on RedHat 8.0 using RedHat's BLAS and LAPACK.
Excellent. I guess the comment should disappear.
Latest cvs gives the following test error: ,---- | Test of inplace operations and rich comparisons | Traceback (most recent call last): | File "<stdin>", line 1, in ? | File "/usr/lib/python2.2/site-packages/numarray/testall.py", line 19, in test | result = eval(p+".test()") | File "<string>", line 0, in ? | File "/usr/lib/python2.2/site-packages/numarray/ma/dtest.py", line 635, in test | test8() | File "/usr/lib/python2.2/site-packages/numarray/ma/dtest.py", line 434, in test8 | x *= 2.0 | TypeError: can't multiply sequence to non-int | >>> `----
This is a known bug in Python, fixed in 2.2.2 and up.
Moreover I have a compilation issue which is probably a gcc bug, but here we go: ,---- | > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC -IInclude/numarray -I/usr/include/python2.2 -c Src/_ufuncComplex32module.c -o build/temp.linux-i686-2.2/_ufuncComplex32module.o -g -march=pentium4 -pipe -Wall | Src/_ufuncComplex32module.c: In function `multiply_Complex32_reduce': | Src/_ufuncComplex32module.c:401: unable to find a register to spill in class `FLOAT_REGS' | Src/_ufuncComplex32module.c:401: this is the insn: | (insn 65 63 67 (set (reg/v:DF 10 st(2) [74]) | (float_extend:DF (subreg:SF (reg/v:DI 21 rxmm0 [71]) 0))) 133 {*extendsfdf2_1} (nil) | (nil)) | Src/_ufuncComplex32module.c:401: confused by earlier errors, bailing out `---- (If I compile with -march=pentium3 it works just fine.)
Maybe someone has a comment here? (If I have some more time I'll file a gcc bug report.)
What version of Python and gcc was this? (I don't normally use /usr/bin/python, but stock RH 8.0 seems to work OK for me)
Greetings, Jochen -- Todd Miller <jmiller@stsci.edu>