[PyKDE] exception handling problems with sip

[Phil Thompson]

On Thursday 13 April 2006 11:15 am, Jacob M. Burbach wrote:
> On Thursday 13 April 2006 5:41, Jacob M. Burbach wrote:
> > On Tuesday 11 April 2006 9:29, Jacob M. Burbach wrote:
> > > On Monday 10 April 2006 4:50, Jacob M. Burbach wrote:
> > > > Was hesitant to post to list about this being unsure if its actually
> > > > a problem with sip(the generated code look fine). But after a series
> > > > of tests the problem only arises when using sip so...
> > > >
> > > > I'm wrapping a C++ library which makes heavy use of exceptions for
> > > > its error handling, theres a base Exception class which more specific
> > > > exceptions are derived from.
> > > >
> > > > Everything seemed to be working fine, until building the extension
> > > > module without debug symbols. Without debug the exceptions were no
> > > > longer caught and cause the program to abort. For some reason, when
> > > > built without debug, all exceptions are then received ONLY as the
> > > > base Exception class.
> > > >
> > > > try {
> > > > 	throw SpecificException();
> > > > }
> > > > catch (SpecificException& sipExceptionRef) {
> > > > 	// Works as expected when built with debug symbols.
> > > > 	// NOT caught when built without debug symbols.
> > > > 	...
> > > > }
> > > >
> > > > I am really confused about what is going on here...
> > > >
> > > > I've put together a small test package containing a tiny C++ library
> > > > that throws exceptions, along with the sip files to build a wrapper
> > > > for it. I also included handwritten python wrapper to show that the
> > > > problem is only when using sip. See the README in the package for
> > > > more details...
> > > >
> > > > http://home.cfl.rr.com/filedump/sip_exception_testcase.tar.bz2
> > > >
> > > > using sip 4.4.1 and Python 2.4
> > >
> > > Am I really the only one to come across this problem?
> > >
> > > Tested: gcc-3.3 with sip-4.4.1 and python2.3
> > > Tested: gcc-3.4.5 with (sip-4.4.1|sip-snapshot) and python2.4
> > >
> > > Same behaviour with all.
> > >
> > > If anyone would be willing to try the test case out and report back, or
> > > can think of anything that might cause this, or anything I can try to
> > > fix this I would greatly appreciate it.
> >
> > Well if I weren't blind I probably would have noticed that the only real
> > difference in the compiler output between debug/ndebug was the addition
> > of `-Wl,--version-script=Foo.exp'.
> >
> > After removing this bit from the Makefile the problem does go away. So I
> > guess now the question is, what exactly is this flag for, and why does it
> > break the module?
>
> Well, if for nothing else than to document the solution. If you run into
> this problem, setting `export_all' to true in your configuration object
> before creating the makefiles will disable the problem flag.
>
> cfg = sipconfig.Configuration()
> cfg.export_all = True
> SIPModuleMakefile(configuration = cfg, ...)
>
> After browsing through `sipconfig.py' it seems this flag is for deciding
> which symbols to export, to help keep libs smaller? I wonder though if this
> flag should be enabled by default in light of these nasty side affects?

Apologies for taking a while to get to this...

The -a flag to SIP's configure.py sets the export_all flag. It's documented in 
the SIP docs, but not in the output of "sip -h" (because it's really there as 
a temporary measure to allow the old, pre-4.2, behaviour to be restored).

As the old behaviour seems to be required in this case (although I don't quite 
understand why), and the -a flag is too inflexible (as it affects every 
module), I've added a "export_all" argument to ModuleMakefile.__init__(). Set 
this to "1" when constructing your SIPModuleMakefile instance in your 
configure.py and everything should be Ok.

Phil