GNOME Bugzilla – Bug 675516
Win32: Don't start a DBus server when built as static library
Last modified: 2013-08-25 19:27:13 UTC
Created attachment 213501 [details] [review] Proposed patch The new Win32 DBus server code which was recently introduced works by retrieving the path of the gio DLL and using rundll32.exe to create a new process which starts a DBus server using the gio DLL. This doesn't work when GLib is built as a static library as there is no gio DLL available in that case. Therefore the code which tries to start a DBus server using the above steps doesn't have to be executed as it will always fail. Attached patch makes sure that no attempt is done to start a DBus server when using a static compiled GLib and that a proper error message is automatically returned to the caller. This also fixes a compilation failure which occurs when GLib is compiled as static library Please apply to both master and 2.32 branches
Review of attachment 213501 [details] [review]: ::: gio/gdbusaddress.c @@ +1395,3 @@ if (address == NULL) { gio_path[MAX_PATH] = 0; Adding the #ifdef would introduce a new unused variable compiler warning for the !DLL_EXPORT case. Might be a good idea to move gio_path variable declaration down here to the "if (address == NULL)" scope to fix this.
Created attachment 222585 [details] [review] Proposed patch (try2) Resolved the unused variable warning
I took another look at the patch and I think it would be better to (try to) fix the logic up so that the DBus server can actually work when gio is built as a static lib. What the proposed patches do so far is to just ifdef the code out that starts the DBus server, effectively making it useless for the static build. I'm going to attach another patch that attempts to make it work, without killing the autostart code.
Created attachment 230445 [details] [review] win32: Fix GDBusDaemon build when glib is built as a static lib This makes sure not to ifdef _g_io_win32_get_module() out when glib is built as a static lib, and also fixes it to work when DllMain isn't available.
Kalev said on irc that the last patch uses a symbol that's not available on win2k... I think that's completely fine and long overdue :) That's said, let's at least mention it in the changelog
Dropping support for win2k is fine by me, and indeed long overdue. Bug #637565 also mentions the gtk.org website and there's maybe other stuff that would need to mention this change ?
Thanks, I've updated the commit message.
Created attachment 230455 [details] [review] win32: Fix GDBusDaemon build when glib is built as a static lib This makes sure not to ifdef _g_io_win32_get_module() out when glib is built as a static lib, and also fixes it to work when DllMain isn't available. The implementation uses GetModuleHandleEx() which is only available on Windows XP and later, so this commit effectively drops the Windows 2000 support in glib. Earlier commit 731b4699 already took care of defining _WIN32_WINNT to support the Windows XP API.
I'm +1 to the patch from Kalev as well Win2k support probably was broken for a long time already as one of the latest win2k compatibility commits - 9a88613 - only has any effect when GLib is built using the mingw-w64 toolchain or MSVC. The mingw.org toolchain doesn't provide wspiapi.h and this is the header which provides win2k compatibility for getaddrinfo, getnameinfo and freeaddrinfo
Review of attachment 222585 [details] [review]: ok
Review of attachment 230455 [details] [review]: ok
Comment on attachment 230455 [details] [review] win32: Fix GDBusDaemon build when glib is built as a static lib Thanks, pushed to master as 80c24d36f2525d83e458ebbdf62fdbd085945a02
> Win2k support probably was broken for a long time already Not true, I'm using glib cross compiled using fedora (so with mingw-w64) on W2K for a long time, it worked nicely. So can this please be implemented using the attached patch? The gnetworking.h includes are needed to pull in wspiapi.h, for the freeaddrinfo W2k compatibility.
Created attachment 253072 [details] [review] make glib work again on Windows 2000