I post this message on behalf of John Emmas. Hope I can get it through
to the gtkmm-list.
Kjell
-------- Ursprungligt meddelande --------
Ämne: Fwd: Re: Gtk::SpinButton crash
Datum: Tue, 03 Dec 2013 09:52:40 +0000
Från: John Emmas <john...@tiscali.co.uk>
Till: Kjell Ahlstedt <kjell.ahlst...@bredband.net>
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 --------
Subject: Re: Gtk::SpinButton crash
Date: Sat, 30 Nov 2013 10:55:42 +0000
From: John Emmas <john...@tiscali.co.uk>
CC: gtkmm <gtkmm-list@gnome.org>
FOUND IT !!!!
On 29/11/2013 19:19, Kjell Ahlstedt wrote:
Is it possible that you have some inconsistency between glibmm and gtkmm?
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
_______________________________________________
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list
