Hi, I'm Todd Miller and I work at STSCI on Numarray. Two people have reported problems with compiling Numarray-0.11 or 0.2 with GCC on SPARC. There are two problems: 1. Compiling the _ufuncmodule.c using gcc-2.95 on a SPARC (with the default switches) uses tons of virtual memory and typically fails. a. This can be avoided by adding the compilation flags: EXTRA_COMPILE_ARGS=["-O0", "-Wno-return-type"] to your setup.py when compiling *numarray*. b. Alternately, you can wait for numarray-0.3 which will partition the ufuncmodule into smaller compilation units. We suspect these will avoid the problem naturally and permit the use of optimization. c. Lastly, if you have Sun cc, you might want to try using it instead of gcc. This is what we do at STSCI. You need to recompile Python itself if you want to do this and your python was already compiled with gcc. 2. Python compiled with gcc generates misaligned storage within buffer objects. Numarray-0.2 is dependent on the problematic variant of the buffer object so if you want to use Float64 or Complex128 on a SPARC you may experience core dumps. a. I have a non-portable patch which worked for me with gcc-2.95 on SPARC. I can e-mail this to anyone interested. Apply this patch and recompile *python*. b. You might be able to fix this with gcc compilation switches for Python: try -munaligned-doubles and recompile *python*. c. Numarray-0.3 will address this issue by providing its own minimal memory object which features correctly aligned storage. This solution will not require recompiling python, but won't be available until numarray-0.3. d. Python compiled with Sun cc using the default switches doesn't manifest this bug. If you have Sun cc, you may want to recompile *python* using that. In general, I think the "better part of valor" is probably to wait 3 weeks for numarray-0.3 when both issues should be addressed. If you want to try numarray-0.2 now with GCC on a SPARC, I hope some of these ideas work for you. Todd -- Todd Miller jmiller@stsci.edu STSCI / SSG (410) 338 4576