Re: gtkmm2.4 and MSVC (again)

[Cedric Gustin <cedric gustin swing be>]

Timothy M. Shead wrote:

> Well, some unglamorous stuff: I've verified that what gets set in 
> Glib::ObjectBase::_set_current_wrapper() is the same as what gets 
> returned by Glib::ObjectBase::_get_current_wrapper().
>
> The dominance thing seems like it's worth looking into, I have no idea 
> what it means, will be looking it up this evening.
>
> One other possibility that occurs to me that perhaps this is a problem 
> with calling virtual functions in a constructor, didn't you say that 
> moving the call to show() in your example makes things work? 

I guess I found the problem: it has nothing to do with gtkmm.

Basically gendef does not export static class members correctly into the
DLL. Here is an example

http://www.pcpm.ucl.ac.be/~gustin/tmp/gendef_static.zip

With the GENDEF_API tags commented out, the static class members are not 
correctly injected from the DLL into the main process memory space. 
Tagging these members with GENDEF_API (which is basically dllexport) 
works "sometimes" on my machine, meaning that there is some incorrect 
memory lookup somewhere and a conflict between the DLL and main process 
memory spaces. Unfortunately there are many static class members in 
glibmm/gtkmm !!!

I suppose the only solution to have a stable build of gtkmm is to get 
rid of gendef and use the good old "dllexport/dllimport"-tagged classes 
and global functions. I know this is a lot of work and will probably 
involve some tweaking of the m4 scripts. I have already created a simple 
python script that tags the classes/structs with the appropriate 
GLIBMM/GTKMM_API macro (except the templated classes that are not dll 
exported.

Cedric