Re: Strange initialization problem with Gtk::Main

[Murray Cumming <murrayc murrayc com>]

On Mon, 2013-10-28 at 18:42 +0000, John Emmas wrote:
> Forgive me if this isn't the right place for asking questions about 
> glibmm.  I couldn't find a specific mailing list for it.
>
> I have 2 x gtkmm applications, both written using MSVC.  I should add 
> that I have several years experience with MSVC, glib, gtk and glibmm/gtkmm.
>
> Pretty much the very first thing that both apps do is to create a 
> Gtk::Main object.  However, the smaller app just creates a local (stack 
> based) object as the first thing in main().  The larger app allocates a 
> Gtk::Main object using 'new()'.  Both methods result in a call to 
> 'Gtk::Main:init()' which, in turn, results in a call to 
> 'Gtk::Main::init_gtkmm_internals()'.  Both functions can be found in 
> 'gtk/gtkmm/main.cc'.  'init_gtkmm_internals' then calls 'Gio::init()'' 
> which then calls 'Gio::wrap_init()' (which is in 
> 'glibmm/gio/giomm/wrap_init.cc').  So far, so good.
>
> AFAICT the execution path is absolutely identical for both programs.  
> The same functions get called in the same order with no apparent 
> problems - BUT - at line 456 of 'gio/giomm/wrap_init.cc' there's a 
> comment which says:-
>
>        // Register the gtkmm types
>
> That comment is followed by around 100 calls to "whatever::get_type()".  
> In the small app, every call succeeds.  In the larger app, every call 
> fails and I'm totally baffled as to why. One possible explanation is 
> that for simplicity, I built gtkmm and glibmm as static libs, rather 
> than DLLs.  At the time I remember getting told that to build as Windows 
> DLLs I needed a utility called "gendef" but there was some doubt about 
> how diligently it was being kept up-to-date, so a static library build 
> seemed simpler - but now I'm not so sure....
>
> In the smaller app it makes no difference as everything is contained in 
> the main exe.  But the larger app uses some DLLs.  Some of those DLLs 
> (and the main app itself) need to link to glibmm and gtkmm so of course, 
> each will have its own copy of glibmm and gtkmm, rather than them being 
> shared objects.  Could that be causing a problem like this??

What is the actual problem that you are seeing?

-- 
Murray Cumming
murrayc murrayc com
www.murrayc.com
www.openismus.com