Re: compiling gtkmm with atkmm support fails in implementor.cc



>codekiddy - can you try the above example and let us know if you also see a hang at that line?  Tomorrow I'll try rebuilding (this time with GTKMM_ATKMM_ENABLED #undef'd) just to confirm that it doesn't then fail.

Yes of course, re-building GTKMM now with #define GTKMM_ATKMM_ENABLED 1
I will post my results as soon as possible.

On Tue, Nov 17, 2015 at 7:28 PM, John Emmas <john creativepost co uk> wrote:
On 17/11/2015 15:54, Kjell Ahlstedt wrote:

The question now is: Why is pCppObject_->unreference() called in the RefPtr destructor when gtkmm,
atkmm and glibmm are built with MSVC? Who sets pCppObject_ to something != nullptr? Or isn't RefPtr's default constructor executed when the Gtk::Window is created?


RefPtr is proving tricky to debug into (maybe because it's a template - and inline?)  However while trying it, I discovered something slightly more worrying.  Even this fails when GTKMM_ATKMM_ENABLED is #defined:-

    int main (int argc, char *argv[])
    {
        Gtk::Main       *app = new Gtk::Main (&argc, &argv);
        Gtk::Window  *mainWnd = new Gtk::Window;

        delete mainWnd;  // <-- hangs here !!
        delete app;

        return 0;
    }

codekiddy - can you try the above example and let us know if you also see a hang at that line?  Tomorrow I'll try rebuilding (this time with GTKMM_ATKMM_ENABLED #undef'd) just to confirm that it doesn't then fail.

John



_______________________________________________
gtkmm-list mailing list
gtkmm-list gnome org
https://mail.gnome.org/mailman/listinfo/gtkmm-list




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]