Thanks, it builds correctly now. But since cairo has a small bug that prevents any win32 cairo based program running, I didn't test the bug you mentioned earlier. Now, I hacked cairo to make it work with GtkTests. The patch for cairo is attached. I'm not sure if it's correct or not, but it works for me. I tested the bug 552678, it's not solved by my patch. The problem seems lurking in GdipBitmapGetPixel (bitmap, x, y, &pixel), which emits an exception:"First-chance exception at 0x77506136 in gdi+.exe: 0xC0000005: Access violation reading location 0x00159000" and returns a Win32Error. Sorry that I can't help further. Best Regards Shixin Zeng On Thu, Aug 20, 2009 at 3:47 PM, Tor Lillqvist<tml iki fi> wrote: >> I spent a day on building gtk head on win32 by utilizing OAH >> (https://launchpad.net/oah) and came up with these small patches. > > Thanks. I went through them and they looked fine. I wonder if the > patch to io-gdip-utils.c could fix the problem with the GDI+ -based > pixbuf loaders (http://bugzilla.gnome.org/show_bug.cgi?id=552678 )? > > The 0004-include-gdk-gdkinternals.h.patch isn't necessary. There is a > declaration of struct _GdkWindowObject also in gdkwindow.h (in > addition to the one in gdkinternals.h) which is the one that should be > seen when compiling gtkmain.c. Presumably you don't get that in your > compilation because you incorrectly have GDK_COMPILATION defined also > when compiling the gtk DLL? > > The 0005-export-_gdk_drawable_impl_win32_get_type-for-gtkplug.patch > should not be necessary either. Do you have INSIDE_GDK_WIN32 defined > while compiling gtk? It is supposed to be defined only when compiling > the code in gdk/win32. > > I will apply the other patches, commit and push. > > --tml >
Attachment:
0001-initialize-clip_region-when-creating-a-new-win32_sur.patch
Description: Binary data