|
I post this message on behalf of John Emmas. Hope I
can get it through to the gtkmm-list. Kjell -------- Ursprungligt meddelande --------
Hi Kjell, After several days I still cannot post to gtkmm-list. I've no idea why my posts are all getting returned all of a sudden but it seems like some kind of technical issue. Anyway, here's what I wanted to tell you about my recent Gtk::SpinButton issue:- -------- Original Message --------
FOUND IT !!!!
On 29/11/2013 19:19, Kjell Ahlstedt wrote:
Yes - in fact there were inconsistencies in the way the following four libraries get built, compared to everything else:- glibmm giomm atkmm gdkmm In the case of glibmm the discrepancy was my fault. In the other three cases it's mostly down to their config files. 1) First glibmm (which was my fault). When I originally built glibmm (4 years ago) I needed to build it as a static library. This meant me needing to modify glibmmconfig.h to ensure that GLIBMM_DLL was undefined. Very recently, I changed to building as a DLL but I'd forgotten about my 4-year old mod. I've now fixed it and things have improved enormously! 2) giomm and atkmm - Essentially, these had the same problem as glibmm but in these two cases it wasn't my fault. Here's a sample section of code (from giommconfig.h.in):- // Enable DLL-specific stuff only when not building a static library #if !defined(__CYGWIN__) && defined(__MINGW32__) && !defined(GIOMM_STATIC_LIB) # define GIOMM_DLL 1 #endif #ifdef GIOMM_DLL # if defined(GIOMM_BUILD) && defined(_WINDLL) /* Do not dllexport as it is handled by gendef on MSVC */ # define GIOMM_API # elif !defined(GIOMM_BUILD) # define GIOMM_API __declspec(dllimport) # else /* Build a static library */ # define GIOMM_API # endif /* GIOMM_BUILD - _WINDLL */ #else # define GIOMM_API #endif /* GIOMM_DLL */ atkmm is essentially the same. Notice that when building as a DLL (with MSVC) GIOMM_DLL will NOT be defined. A module definition file ensures that the symbols do get exported correctly from the built DLL but they won't get imported properly by dependent libraries (more about this later). 3) gdkmm - AFAICT there's no declaration of any GDKMM_API. Does this mean that gdkmm objects share the declaration of GTKMM_API? Or is the intention that gdkmm should get built as a static lib? Please could someone clarify this for me? So... what problem does all this cause...? Basically, __declspec(dllimport) won't be defined when building libraries that link to giomm, atkmm (and possibly gdkmm). When declspec(dllimport) isn't used by an importing library, functions get correctly imported (via some 'thunk' type mechanism) but exported data doesn't get imported properly. IIRC what gets imported is the address of the data, rather than its value. That's why I was seeing ludicrously high numbers for 'Glib::quark_' and 'Glib::quark_cpp_wrapper_deleted_'. I once found an article somewhere which explained it all (in fact, I think it was someone here who directed me to it). I could try to find it again if anyone wants to check it. For the time being I've made some temporary fixes locally but I'd suggest that the devs for atkmm, giomm and gdkmm should get together and devise a common strategy so that MSVC builds will link correctly. Right at the top of 'glibmmconfig.h.in' you'll find 18 lines of code that make this work for glibmm. That same strategy should probably get adopted for those other libraries. Of course, if the other libraries don't export any data, there won't be any immediate problem (just a problem "waiting to happen"). Thanks for everyone's help with this (and an especially big thanks to Kjell) !! Seems to be working fine at last ! John |