GNOME Bugzilla – Bug 619243
Glib fails to build under MinGW
Last modified: 2010-05-21 08:59:07 UTC
Created attachment 161596 [details] [review] Avoid the "interface" symbol by using "interface_name" instead All Glib versions since 2.25.4 fail to build under MinGW. The builds break with the following error message: ---------------------------------------------------------------------------- In file included from ../gio/gio.h:102:0, from gwin32outputstream.h:27, from gwin32outputstream.c:33: ../gio/gdbusmessage.h:71:88: error: expected ';', ',' or ')' before 'struct' ../gio/gdbusmessage.h:75:88: error: expected ';', ',' or ')' before 'struct' ---------------------------------------------------------------------------- This is because two functions of gio/gdbusmessage.h take an argument "interface", but "interface" is already defined in the w32api headers as "struct". The attached patch fixes the issue by renaming the argument from "interface" to "interface_name".
Created attachment 161599 [details] [review] Add missing #includes The attached patch is needed in addition to the previous patch, and fixes some more build errors by adding lots of missing #includes. With this patch, there's just one final build error: ----------------------------------------------------------------------------- gdbusauthmechanismsha1.c: In function 'ensure_keyring_directory': gdbusauthmechanismsha1.c:283:2: error: #error Please implement permission checking on non-UNIX platforms ----------------------------------------------------------------------------- In other words: Glib >= 2.25.4 can't build under Windows because of an incomplete implementation. Too sad.
I am sure that the developers are well aware that there might be, and indeed are, build problems on Windows in the bleeding edge, and that they are working on it. You can be assured that the intent of everybody concerned is that GLib will continue to build and work on Windows, and especially new features are intended to be usable (as far as possible) on Windows, too. At least, that is my impression. But note that Windows is not the main development platform of any of the people actually writing new code into GLib at the moment. To the best of my knowledge, neither is for instance Solaris, and I am rather sure that the current bleeding edge code doesn't compile on it either, or on any other non-Linux Unix system. It isn't really that useful to file bugs for development releases very early after lots of new code has been integrated. It's more useful to discuss problematic implementation issues on Windows, perhaps with patches, on the gtk-devel-list. Or talk on #gtk+ when relevant people are present (i.e. those who have written new code). (Actually, I don't understand why such a rush in doing releases (tarballs) so quickly after adding lots of new code. But, on the other hand, better to release too often than too rarely, I guess.)
The actual problem reported here, "interface" clashing with some Windows headers, has already been fixed.
(In reply to comment #3) > The actual problem reported here, "interface" clashing with some Windows > headers, has already been fixed. For the sake of completeness, there were _two_ actual problems here: the "interface" bug and the missing #includes. BTW, I wasn't able to figure out why those #includes are needed for Windows but not for other platforms. Also, sorry for the "spam". It seems that I had wrong expectations on the development releases of Glib. I thought that these were expected to at least _compile_ under Windows, and that it could be safely called a "blocker bug" if they fail to do so for 3 subsequent releases.
> I wasn't able to figure out why those #includes are > needed for Windows but not for other platforms. I think it is because on Unix the source files in question include some header which includes <gio/gio.h> (which then includes all public gio headers, so actually for Unix it is pointless to separately include any of the public headers). What I don't understand is why the sources can't simply all include "gio.h" instead of including separate headers?
(The non-public headers would still have to be included separately, of course.)