Re: gtkmm2.4 and MSVC (again)

Cedric Gustin wrote:

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.

That's some kick-ass detective work! I suppose that the hypothesis in this case is that the RTTI data (which is presumably static or something like it) is getting lost too, then?


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