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 <jm...@st...>
|
