[cable] generated python wrapper signals EXC_BAD_ACCESS on MacOSX

[Kaben Nanlohy]

Brad --

The problem relates to shared libraries, and I did not find a solution.
Per an example that I found in the Insight source code, I generated two
shared libraries and one module :

	libhello.dylib,
	libSwigRuntimePython.dylib,
	_DemoCableSwigPython.so.

libSwigRuntimePython.dylib and _DemoCableSwigPython.so contained object
files built from CableSwig generated files swigrunPython.cc and
wrap_DemoPython.cc, respectively. wrap_DemoPython.cc contained the line

	#define SWIG_NOINCLUDE

because it was generated by cswig using the -c option.

_DemoCableSwigPython.so linked to libhello.dylib and
libSwigRuntimePython.dylib without complaint. The crash occurred, I
think, when code in _DemoCableSwigPython.so tried to call code in
libSwigRuntimePython.dylib, but again, I don't know why.

***

A short term solution that works fine for me is to completely define the
wrapping in one source file and module, e.g. :

/* wrap_Demo.cc */
#include "fubar.hh"
#include "hello.hh"
#ifdef CABLE_CONFIGURATION
namespace _cable_
{ 
  const char* const package = "DemoCableSwigPython";
  const char* const group = "DemoCableSwigPython";
  namespace wrappers { typedef ::fubar fubar; }
  namespace wrappers { typedef ::hello hello; }
}
#endif

and generating _DemoCableSwigPython.so linked with, say, libhello.dylib
and libfubar.dylib, and that contains a Swig Python runtime (if that is
what you call it).

On the other hand each such module contains such a runtime, and I guess
that this would cause problems if I wanted to import more than one such
module ?

In any case I am up and running. Thanks for your help.

-- Kaben.


The following works in the short term :

On Mon, 9 Feb 2004, Kaben Nanlohy wrote:

> The short answer : PyErr_Occurred () at Python/errors.c:81 is just the
> end of the function. That is, I think, PyErr_Occurred () doesn't
> remember how/where to return.
> 
> Of course, this information is less than useful. I haven't found the
> start of the clobbering -- this Python executable is optimized, and I'm
> not good at debugging optimized code. I hope for more insight when I
> compare the swig-only object construction, and I may have better luck
> with an unoptimized Python.