Re: Gtk+ 2.3 ABI breakage or Gtk-Error **: incompatible build!

[Hans Breuer <Hans Breuer org>]

At 10:38 31.10.03 -0500, Owen Taylor wrote:
>On Sat, 2003-11-01 at 09:44, Hans Breuer wrote:
>
>> Looking deeper into it :
>> 
>> The flags started from GtkWindow::allow_shrink : 1
>> are now 33 in sum which triggers the above sizeof check failure.
>> 
>> Also the addition of GtkWindow::(above|below)_initially changes
>> the meaning of the following flags, which is another ABI
>> incompatible change ...
>
>Hmm, MSVC must pack things different. With GCC everything from
>allow shring to destroy with parent will go in the 16 bits
>after configure_request_count, so we go from 16 to 17 bits
>in a 32 bit space, not 32 to 33 bits in a 32 bit space.
>
It certainly appears so as the stripped down output from my
little test program shows :

D:\devel\my-gtk\gtk-2-2\tests>testabi
Class   Instance        Name
68      12      GObject
80      16       GtkObject
364     60        GtkWidget
416     68         GtkContainer
416     72          GtkBin
456     148          GtkWindow

offset  class::member
72      GtkWindow::title
112     GtkWindow::configure_request_count
120     GtkWindow::frame_left
144     GtkWindow::screen

D:\devel\my-gtk\gtk+\tests>testabi
Class   Instance        Name
456     152          GtkWindow

offset  class::member
112     GtkWindow::configure_request_count
124     GtkWindow::frame_left


>Still, it's trivial to fix by putting the flags into 
>GtkWindowPrivate. And the fact that some of the other bit
>fields got shifted around in the structure is something I'd
>rather avoid anyways.
>
Just moved the disturbing flags to GtkWindowPrivate and it
works fine again. [Not providing a diff yet as there has
changed some other stuff in my local tree which isn't
finished, i.e. GtkFileSystemWin32] 

>> Further, isn't always true above_initially == !below_initially.
>> So there would be only one flag needed ?
>
>No, that's not true - above is above all windows, below below
>all windows.
>
Interesting, is this just a temporary state (initially?) so it
does affect only the Z-order when the window is showm? Or should
the window keep it state even when the user clicks on some other
toplevel (i.e. _keep_above, or HWND_TOPMOST in windoze parlance) ?

>> But even fixing this won't give us back a compatiple ABI. Apparently
>> some gobject has changed size as well (or at least I needed to recompile
>> Pango as well to get a not crashing testfilechooser ...)
>
>I haven't seen any problems switching back and forth between GTK+-2.2
>and GTK+-2.4 builds. So, it probably is some other MSVC specific
>problem. Can you track it down?
>
If I fully understand the rules, I can try. But if I have done
something unsupported it's probably not worth the effort.

As I understand every visible struct needs to keep it's size and
even the bitfields need to keep their place. So the patch to
gtkwindow.[hc] needs to be applied.

But is it really supported to mix like : newest GObject, newest Gtk
with some older build of Pango laying around ? (This is what
seems to have caused the other problem, and I'm not even sure
what version of Pango it was ;-)

Thanks,
	Hans

-------- Hans "at" Breuer "dot" Org -----------
Tell me what you need, and I'll tell you how to 
get along without it.                -- Dilbert