Re: [glade--] Never use g++-2.95 with glademm/gtkmm2 !!! was: unable to add new members to derived class
- From: Christof Petig <christof petig-baender de>
- To: murrayc usa net
- Cc: Bob Koutsky <bck webhome cz>, glademm-list gnome org, ManuProC Entwickler <manuproc-developer-de lists berlios de>
- Subject: Re: [glade--] Never use g++-2.95 with glademm/gtkmm2 !!! was: unable to add new members to derived class
- Date: Tue, 26 Nov 2002 10:27:02 +0100
Morale: If you use 2.95 and gtkmm2 never let glademm add any widget to
any container (unless you do not plan to put _any_ member in the user
class).
Sigh
Murray Cumming wrote:
On Mon, 2002-11-25 at 14:56, Christof Petig wrote:
It is indeed a compiler bug. The bug does not occur with g++-3.2.1. But
the but does not occur with gtkmm-1.2 and g++-2.95.4.
I hope debian/unstable switches to g++-3.2 soon, so I can forget about
the old compiler (and still use the distro's libraries). I don't have
the slightest idea about what is causing this bug on 2.0 and evading it
on 1.2 ... (adding an integer to an empty class is not so uncommon ...)
Have you ruled out the gcc 2.9x bug mentioned in the gtkmm FAQ?
It is the same, although there's no way to work around it (besides
omitting any inheritance or patching glademm to add the widgets in the
user ctor with a method (which is evil and unnecessary IMHO)).
Offending code: (container.cc:514, #1 below)
void Container_Class::add_callback(GtkContainer* self, GtkWidget* p0)
{
CppObjectType *const obj = dynamic_cast<CppObjectType*>(
Glib::ObjectBase::_get_current_wrapper((GObject*)self));
if(obj && obj->is_derived_())
Here's the backtrace (sorry, debian stripped the library, there's no
-dbg variant, and I'm not overly keen to build gtkmm with _2.95_ again):
#0 0x0f9b98d8 in Glib::ObjectBase::is_derived_ ()
from /usr/lib/libglibmm-2.0.so.1
#1 0x0fef5e84 in Gtk::Container_Class::add_callback ()
from /usr/lib/libgtkmm-2.0.so.1
#2 0x0f731680 in g_cclosure_marshal_VOID__OBJECT (closure=0x100589f0,
return_value=0xffef9bc, n_param_values=1, param_values=0x7ffff708,
invocation_hint=0xf9e5c8c, marshal_data=0xfef5e08) at gmarshal.c:636
#3 0x0f7189e0 in g_type_class_meta_marshal (closure=0x100589f0,
return_value=0x0, n_param_values=2, param_values=0x7ffff708,
invocation_hint=0x7ffff610, marshal_data=0x16c) at gclosure.c:514
#4 0x0f718658 in g_closure_invoke (closure=0x100589f0, return_value=0x0,
n_param_values=2, param_values=0x7ffff708, invocation_hint=0x7ffff610)
at gclosure.c:437
#5 0x0f72f6c8 in signal_emit_unlocked_R (node=0x10058a38, detail=0,
instance=0x1005bb60, emission_return=0x0,
instance_and_params=0x7ffff708)
at gsignal.c:2275
#6 0x0f72e3ac in g_signal_emit_valist (instance=0x1005bb60, signal_id=0,
detail=0, var_args=0x7ffff9d0) at gsignal.c:2104
#7 0x0fb9b720 in gtk_signal_emit (object=0x1005bb60, signal_id=62)
at gtksignal.c:355
#8 0x0fafab5c in gtk_container_add (container=0x1005bb60,
widget=0x1005f518)
at gtkcontainer.c:859
#9 0x0fef4fc8 in Gtk::Container::add () from /usr/lib/libgtkmm-2.0.so.1
#10 0x100060ec in window1_glade::window1_glade (this=0x10050730,
__in_chrg=0)
at window1_glade.cc:27
#11 0x10005bd8 in window1::window1 (this=0x10050730, __in_chrg=1)
at window1.hh:17
#12 0x100044c0 in main (argc=1, argv=0x7ffffb84) at bugtest.cc:17
#13 0x0f3d4e8c in __libc_start_main () from /lib/libc.so.6
PS: This was still 2.0.0.
Yours
Christof
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]