scipy on irix -- problems with bsplines
SciPy builds failed in the signal module when trying to build on an SGI system. Has anyone seen the following error when building something on IRIX with gcc 2.95.2? 25 sgi> gcc -c C_bspline_util.c C_bspline_util.c: In function `C_IIR_order1': C_bspline_util.c:28: Unable to access real part of complex value in a hard register on this target 26 sgi> gcc -c Z_bspline_util.c 27 sgi> It happens in several of the bspline files for complex values, but not for double complex. The relevant lines of code from bspline_util.c are: 21 void 22 C_IIR_order1 (a1, a2, x, y, N, stridex, stridey) 23 __complex__ float a1; 24 __complex__ float a2; 25 __complex__ float *x; 26 __complex__ float *y; 27 int N, stridex, stridey; 28 { 29 __complex__ float *yvec = y+stridey; 30 __complex__ float *xvec = x+stridex; 31 int n; 32 33 for (n=1; n < N; n++) { 34 *yvec = *xvec * a1 + *(yvec-stridey) * a2; 35 yvec += stridey; 36 xvec += stridex; 37 } 38 } The only references I saw on the net were to previous problems when building libstdc++ with 2.95.1 on SGI and ALPHA machines. The good news is, other than this problem, SciPy builds on IRIX using gcc and linking to the blas and scs(lapack) platform specific libraries. I also tried building python with MIPSPro C compiler and then SciPy using The MIPSPro compiler suite. The python build worked fine after getting readline issues sorted out, and it appeared to work fine. However, python core dumped in the middle of building the flapack wrappers with f2py, so it looks like something is working quite right in the python build. I'd like to get this working, so if anyone has built SciPy/Python entirely with MIPSPro, fill me in on the secrets. Thanks, eric
On Thu, 27 Jun 2002, eric jones wrote:
I also tried building python with MIPSPro C compiler and then SciPy using The MIPSPro compiler suite. The python build worked fine after getting readline issues sorted out, and it appeared to work fine. However, python core dumped in the middle of building the flapack wrappers with f2py, so it looks like something is working quite right in the python build. I'd like to get this working, so if anyone has built SciPy/Python entirely with MIPSPro, fill me in on the secrets.
Did you disable g77 compiler from the header of scipy/linalg/setup_linalg.py? In the latest CVS version of linalg the g77 compiler is forced only for win32. Another question: does your irix have ranlib? In irix64-6.5-2.1 that I can access it is missing. Pearu
I also tried building python with MIPSPro C compiler and then SciPy using The MIPSPro compiler suite. The python build worked fine after
readline issues sorted out, and it appeared to work fine. However, python core dumped in the middle of building the flapack wrappers with f2py, so it looks like something is working quite right in the
getting python
build. I'd like to get this working, so if anyone has built SciPy/Python entirely with MIPSPro, fill me in on the secrets.
Did you disable g77 compiler from the header of scipy/linalg/setup_linalg.py? In the latest CVS version of linalg the g77 compiler is forced only for win32.
I hadn't, but I just tried this, and it still dies at: Reading fortran codes... Reading file '/home/army/eric/third/sgi_cc/SciPy-0.2.0_alpha_103.3566/linalg/flapack. pyf' Post-processing... Block: cgees__user__routines Block: cgees_user_interface Block: cselect Block: dgees__user__routines Block: dgees_user_interface Block: dselect Block: sgees__user__routines Block: sgees_user_interface Block: sselect Block: zgees__user__routines Block: zgees_user_interface Block: zselect Block: flapack Block: sgesv Block: dgesv Block: cgesv Block: zgesv Block: sgetrf Block: dgetrf Block: cgetrf Block: zgetrf Block: sgetrs Block: dgetrs Block: cgetrs Block: zgetrs Block: sgetri Block: dgetri Block: cgetri Block: zgetri Block: sgesdd Bus error (core dumped)
Another question: does your irix have ranlib? In irix64-6.5-2.1 that I can access it is missing.
I just checked, and the machine I'm using does have ranlib. I am using a slightly older build (from the tarballs on the site a few days back). I'll try again soon from the CVS and see how that goes. eric
On Mon, 1 Jul 2002, eric jones wrote:
I hadn't, but I just tried this, and it still dies at:
Reading fortran codes... Reading file '/home/army/eric/third/sgi_cc/SciPy-0.2.0_alpha_103.3566/linalg/flapack. pyf' Post-processing... Block: cgees__user__routines Block: cgees_user_interface Block: cselect Block: dgees__user__routines Block: dgees_user_interface Block: dselect Block: sgees__user__routines Block: sgees_user_interface Block: sselect Block: zgees__user__routines Block: zgees_user_interface Block: zselect Block: flapack Block: sgesv Block: dgesv Block: cgesv Block: zgesv Block: sgetrf Block: dgetrf Block: cgetrf Block: zgetrf Block: sgetrs Block: dgetrs Block: cgetrs Block: zgetrs Block: sgetri Block: dgetri Block: cgetri Block: zgetri Block: sgesdd Bus error (core dumped)
That is strange. Note that f2py2e is a pure Python package and therefore I would not expect any core dumps from using f2py unless Python itself has bugs or there are problems with Python builds. Pearu
-----Original Message----- From: scipy-dev-admin@scipy.net [mailto:scipy-dev-admin@scipy.net] On Behalf Of Pearu Peterson Sent: Thursday, July 04, 2002 4:12 AM To: scipy-dev@scipy.net Subject: RE: [SciPy-dev] scipy on irix -- problems with bsplines
On Mon, 1 Jul 2002, eric jones wrote:
I hadn't, but I just tried this, and it still dies at:
Reading fortran codes... Reading file
'/home/army/eric/third/sgi_cc/SciPy-0.2.0_alpha_103.3566/linalg/flapack.
pyf' Post-processing... Block: cgees__user__routines Block: cgees_user_interface Block: cselect Block: dgees__user__routines Block: dgees_user_interface Block: dselect Block: sgees__user__routines Block: sgees_user_interface Block: sselect Block: zgees__user__routines Block: zgees_user_interface Block: zselect Block: flapack Block: sgesv Block: dgesv Block: cgesv Block: zgesv Block: sgetrf Block: dgetrf Block: cgetrf Block: zgetrf Block: sgetrs Block: dgetrs Block: cgetrs Block: zgetrs Block: sgetri Block: dgetri Block: cgetri Block: zgetri Block: sgesdd Bus error (core dumped)
That is strange. Note that f2py2e is a pure Python package and therefore I would not expect any core dumps from using f2py unless Python itself has bugs or there are problems with Python builds.
Right. I agree. That is what I suspected also. I haven't had time to chase this one further though. The only things slightly unusual about the build are that I built and linked readline and ncurses myself because the system doesn't have those. These were build with gcc. The Python build was built with MIPSPro. I wouldn't have thought readline/ncurses would cause this sort of problem. eric
Hi Eric, On Thu, 27 Jun 2002, eric jones wrote:
I also tried building python with MIPSPro C compiler and then SciPy using The MIPSPro compiler suite. The python build worked fine after getting readline issues sorted out, and it appeared to work fine. However, python core dumped in the middle of building the flapack wrappers with f2py, so it looks like something is working quite right in the python build. I'd like to get this working, so if anyone has built SciPy/Python entirely with MIPSPro, fill me in on the secrets.
I have build SciPy entirely with MIPSPro compilers. Here follows my setup: Python 2.1.1 (#1, Oct 21 2001, 16:10:39) [C] on irix646 Numeric 20.2.1 $ cc -version MIPSpro Compilers: Version 7.30 $ f77 -version MIPSpro Compilers: Version 7.30 No ATLAS. LAPACK (3.3.14) and BLAS are built from their source (the latest SciPy in CVS supports this feature). My guess is that the secret you are looking for is to remove forcing g77 in scipy/setup.py file. All tests (level=10) pass except weave tests. Typical error messages from weave tests are: cc-1132 cc: ERROR File = /usr/include/CC/istream, Line = 43 The class "std::char_traits<char>" has no member "off_type". typedef typename _Traits::off_type off_type; ^ detected during instantiation of class "std::basic_istream<char, std::char_traits<char>>" at line 92 of "/usr/include/CC/strstream" cc-1079 cc: ERROR File = /usr/include/CC/strstream, Line = 136 A type specifier is expected. typedef char_traits<char>::off_type off_type; Regards, Pearu
Hi Eric,
On Thu, 27 Jun 2002, eric jones wrote:
I also tried building python with MIPSPro C compiler and then SciPy using The MIPSPro compiler suite. The python build worked fine after getting readline issues sorted out, and it appeared to work fine. However, python core dumped in the middle of building the flapack wrappers with f2py, so it looks like something is working quite right in the python build. I'd like to get this working, so if anyone has built SciPy/Python entirely with MIPSPro, fill me in on the secrets.
I have build SciPy entirely with MIPSPro compilers. Here follows my setup:
Python 2.1.1 (#1, Oct 21 2001, 16:10:39) [C] on irix646 Numeric 20.2.1 $ cc -version MIPSpro Compilers: Version 7.30 $ f77 -version MIPSpro Compilers: Version 7.30 No ATLAS. LAPACK (3.3.14) and BLAS are built from their source (the latest SciPy in CVS supports this feature).
My guess is that the secret you are looking for is to remove forcing g77 in scipy/setup.py file.
As mentioned, I still failed. I'll try again soon though.
All tests (level=10) pass except weave tests. Typical error messages
from
weave tests are:
cc-1132 cc: ERROR File = /usr/include/CC/istream, Line = 43 The class "std::char_traits<char>" has no member "off_type".
typedef typename _Traits::off_type off_type; ^ detected during instantiation of class "std::basic_istream<char, std::char_traits<char>>" at line 92 of "/usr/include/CC/strstream"
cc-1079 cc: ERROR File = /usr/include/CC/strstream, Line = 136 A type specifier is expected.
typedef char_traits<char>::off_type off_type;
Don't know what this is all about, but I'm betting it is a CXX related issue. Someday, we'll use something a little lighter weight than CXX for the dictionary/list/string conversions and this will all go away (except for the blitz users...). eric
participants (2)
-
eric jones -
Pearu Peterson