Re: gtkmm2.4 and MSVC (again)

["Timothy M. Shead" <tshead k-3d com>]

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
>
> 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.

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?

Cheers,
Tim