I'm trying to analyse some SYS_SEGV errors in Boa
under wxGTK and need to get a debug variant of wxGTK
working. I added the '--enable-debug' flag to the
configure commands in the .spec file in the source RPM
and nulled lib_debug_suffix in the configure files so
as to avoid separately named libraries. From what I
can garner from the documentation nothing else should
be required. However, boa now dumps core with a
SYS_SEGV on startup (not it's normal behaviour!), and
the gdb backtrace doesn't recognise the function name
for the last 50 instructions. Thus I assume it's
bombed in libgtk or some such. Am I missing something
in the wxGTK setup?
John Bell
···
__________________________________________________
Do You Yahoo!?
Yahoo! Games - play chess, backgammon, pool and more http://games.yahoo.com/
I'm trying to analyse some SYS_SEGV errors in Boa
under wxGTK and need to get a debug variant of wxGTK
working. I added the '--enable-debug' flag to the
configure commands in the .spec file in the source RPM
and nulled lib_debug_suffix in the configure files so
as to avoid separately named libraries. From what I
can garner from the documentation nothing else should
be required. However, boa now dumps core with a
SYS_SEGV on startup (not it's normal behaviour!), and
the gdb backtrace doesn't recognise the function name
for the last 50 instructions. Thus I assume it's
bombed in libgtk or some such. Am I missing something
in the wxGTK setup?
The debug and non-debug versions of wxWindows are not binary compatible, so
you need to rebuild wxPython too. When the __WXDEBUG__ macro is defined
then many of the classes/methods will have different signatures etc.
where the "offending" function to the point of failure
reads:
> gint wxapp_pending_callback( gpointer WXUNUSED(data)
)
> {
> if (!wxTheApp) return TRUE;
>
> // when getting called from GDK's time-out
handler
> // we are no longer within GDK's grab on the GUI
> // thread so we must lock it here ourselves
> gdk_threads_enter();
>
> // Sent idle event to all who request them
> wxTheApp->ProcessPendingEvents(); (LINE 176)
The problem is that the wxApp instance created in wxPython has a different
binary layout than the wxApp class used in wxGTK because of being compiled
with different __WXDEBUG__ flags.
···
--
Robin Dunn
Software Craftsman
robin@AllDunn.com Java give you jitters? http://wxPython.org Relax with wxPython!
The debug and non-debug versions of wxWindows are not binary compatible, so
you need to rebuild wxPython too. When the __WXDEBUG__ macro is defined
then many of the classes/methods will have different signatures etc.
where the "offending" function to the point of failure
reads:
> gint wxapp_pending_callback( gpointer WXUNUSED(data)
)
> {
> if (!wxTheApp) return TRUE;
>
> // when getting called from GDK's time-out
handler
> // we are no longer within GDK's grab on the GUI
> // thread so we must lock it here ourselves
> gdk_threads_enter();
>
> // Sent idle event to all who request them
> wxTheApp->ProcessPendingEvents(); (LINE 176)
The problem is that the wxApp instance created in wxPython has a different
binary layout than the wxApp class used in wxGTK because of being compiled
with different __WXDEBUG__ flags.
···
--
Robin Dunn
Software Craftsman
robin@AllDunn.com Java give you jitters? http://wxPython.org Relax with wxPython!