[SciPy-user] Problems building SciPy-0.3 on OS X

[Pearu Peterson]

On Tue, 10 Aug 2004, Tom Loredo wrote:

> > Hmm, the segfault appears while executing pure Python code. 
> 
> Yes.  By the admittedly crude approach of inserting lots of print
> statements, I've determined that it happens in "all_subroutines" in
> Lib/linalg/interface_gen.py:
> 
> 	def all_subroutines(interface_in):
> 		# remove comments
> 		comment_block_exp = re.compile(r'/\*(?:\s|.)*?\*/')
> 		subroutine_exp = re.compile(r'subroutine (?:\s|.)*?end subroutine.*')
> 		function_exp = re.compile(r'function (?:\s|.)*?end function.*')
> 		print '***** Compiled regexps...'
> 		
> 		print '***** stripping comments...'
> 		interface = comment_block_exp.sub('',interface_in)
> 		print '***** finding subrs...'
> 		print interface
> 		subroutine_list = subroutine_exp.findall(interface)
> 		print '***** finding functions...'
> 		function_list = function_exp.findall(interface)
> 		print '***** concatenating...'
> 		subroutine_list = subroutine_list + function_list 
> 		print '***** stripping...'
> 		subroutine_list = map(lambda x: string.strip(x),subroutine_list)
> 		return subroutine_list
> 
> The fault occurs while finding the subroutines via "subroutine_exp.findall(interface)".
> I've printed out "interface" (too long to post here) and there is nothing obvious
> wrong with it, but I don't really know what to expect.  In years of using Python,
> this is the first segfault I've seen running a builtin or library module!

Could you try running setup.py with different version of Python?

Also try saving "interface" string to a file, then from a fresh Python 
session load the string, and apply subroutine_exp.findall to it. Will 
Python crash also then?

> > Also, I'd suggest using CVS version of scipy 
> 
> Yes, I was afraid you'd suggest this.  I'm developing a public package, and
> a frequent comment from potential users is that they don't want to have to
> deal with CVS---they would ideally just want an RPM, though I think they'll
> live with a setup.py.  The CVS barrier is admittedly small in scipy's case,
> but every barrier cuts off another layer of possible users.  The latest
> "official" build really should build on all the major platforms.

I agree. The problem is that currently I don't have access to OSX machines 
and therefore it is rather difficult to guarantee that the scipy build 
will work on OSX. I hope that someone having OSX 10.2 could look into this 
issue and find the cause to these errors.

> > I would disable building xplt for now. To do that, add 'xplt' to the
> > ignore_packages list at the end of setup.py file. And then try 'python 
> > setup.py build' again. 
> 
> I tried that with the CVS version.  No go, same problem:
> 
> 	building extension "scipy.linalg.cblas" sources
> 	  adding 'build/src/scipy/linalg/cblas.pyf' to sources.
> 	  adding 'build/src/fortranobject.c' to sources.
> 	  adding 'build/src' to include_dirs.
> 	building extension "scipy.linalg.flapack" sources
> 	generating flapack interface
> 	Segmentation fault
> 
> I've again inserted print statements and verified that the segfault is
> happening in the same place (using the subroutine_exp regexp).  This
> regexp works fine on earlier modules.
> 
> Is the earlier error (AttributeError: 'NoneType' object has no attribute 'rfind')
> perhaps a clue I'm overlooking (i.e., something is not getting set up on that
> first build attempt, and is getting overlooked on the 2nd attempt)?

I believe that the two issues (the attribute error and the segfault) are 
not releated (upto possible bugs in Python, that's why I suggested 
to disable building xplt in the first place).

Pearu