Re: gtkmm2.4 and MSVC (again)

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

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.


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