I build dbus-src on windows and got the follow error message: ======================================================= [ 41%] Building C object dbus/CMakeFiles/dbus-1.dir/C_/Mat/kderoot/git/dbus-src-git/dbus/dbus-sysdeps-util-win.obj Linking C shared library ..\bin\libdbus-1.dll Creating library file: ..\bin\libdbus-1.dll.a CMakeFiles\dbus-1.dir/objects.a(dbus-sysdeps-win.obj): In function `dbus_atomic_get': C:/Mat/kderoot/git/dbus-src-git/dbus/dbus-sysdeps-win.c:3081: undefined reference to `MemoryBarrier' collect2: ld returned 1 exit status mingw32-make[2]: *** [bin/libdbus-1.dll] Error 1 mingw32-make[1]: *** [dbus/CMakeFiles/dbus-1.dir/all] Error 2 mingw32-make: *** [all] Error 2 emerge fatal error: while running make cmd: mingw32-make emerge fatal error: running python C:\Mat\kderoot\etc\..\emerge\portage\win32lib s-sources\dbus-src\dbus-src-1.4.10-20110302.py compile emerge debug: Task: Emerge stopped after: 0:01:44.040000 ======================================================= My platform is: 32bit / windows7 ming4 4.4.0 dbus git version => 7973504 I found a related post, and seems had a patch for this: http://lists.gnu.org/archive/html/mingw-cross-env-list/2011-09/msg00033.html
Looks like a system bug to me. This function was defined in a header (windows.h / winnt.h) and never implemented anywhere. The MS documentation[1] says it's inline, no DLL is necessary for this. I'd say NOTOURBUG, the bug is in your toolchain. MinGW should not provide declarations for functions it does not implement. Or if it wants to be 100% compatible with the Win32 API, it must implement them. [1] http://msdn.microsoft.com/en-us/library/ms684208(VS.85).aspx
(In reply to comment #1) > Looks like a system bug to me. This function was defined in a header (windows.h > / winnt.h) and never implemented anywhere. The MS documentation[1] says it's > inline, no DLL is necessary for this. > > I'd say NOTOURBUG, the bug is in your toolchain. MinGW should not provide > declarations for functions it does not implement. Or if it wants to be 100% > compatible with the Win32 API, it must implement them. > > [1] http://msdn.microsoft.com/en-us/library/ms684208(VS.85).aspx I got it. Thanks!
Turns out that the MemoryBarrier function/macro is only available on Windows Server 2003 or Vista or up. It's in the link I posted but I failed to take notice. So the D-Bus code should properly avoid it.
If this is the patch you mean: 28 From d7bc1aff67132c09d154999c282e1b391bbe7a39 Mon Sep 17 00:00:00 2001 29 From: mingw-cross-env 30 Date: Fri, 23 Sep 2011 16:24:46 +0200 31 Subject: [PATCH 2/2] add missing MemoryBarrier (mingw-cross-env specific) 32 33 Windows API has this, but it's not in MinGW. 34 See http://lists-archives.org/mingw-users/15935-missing-definition-of-memorybarrier.html 35 36 diff --git a/dbus/dbus-sysdeps-win.c b/dbus/dbus-sysdeps-win.c 37 index b492b09..082225f 100644 38 --- a/dbus/dbus-sysdeps-win.c 39 +++ b/dbus/dbus-sysdeps-win.c 40 @@ -55,6 +55,13 @@ 41 #include <ws2tcpip.h> 42 #include <wincrypt.h> 43 44 +__CRT_INLINE VOID MemoryBarrier(VOID) 45 +{ 46 + LONG Barrier = 0; 47 + __asm__ __volatile__("xchgl %%eax,%0 " 48 + :"=r" (Barrier)); 49 +} 50 + 51 /* Declarations missing in mingw's headers */ 52 extern BOOL WINAPI ConvertStringSidToSidA (LPCSTR StringSid, PSID *Sid); 53 extern BOOL WINAPI ConvertSidToStringSidA (PSID Sid, LPSTR *StringSid); 54 -- will it break compilation in non-mingw32 and/or Vista-or-newer environments? Is this portable to compilers other than gcc? (My guess is "no".) If this is approximately how memory barriers are implemented in the Win32 SDK or whatever it is that provides MemoryBarrier (as an always-inline thing), then surely the distinction isn't between *running* D-Bus on (<=) XP or (>=) Vista, but between compiling D-Bus on an older or newer SDK/compiler/C-runtime?
(In reply to comment #3) > Turns out that the MemoryBarrier function/macro is only available on Windows > Server 2003 or Vista or up. How would that even work, if it's a macro that expands to a compiler intrinsic? Is "only available on Vista+" secret Microsoft code for "only available on the Win32 headers supplied by the Vista+ SDKs" or something? It occurs to me that since InterlockedIncrement is claimed to be a full memory barrier, this could work: #ifdef MemoryBarrier MemoryBarrier (); #else /* do something else that provides a read/write memory barrier, * but exists in pre-Vista Win32 headers and old mingw versions */ volatile long *dummy; InterlockedIncrement (&dummy); #endif desrt, any thoughts on this? Have you had people complain about the corresponding code in GLib, or has nobody tried building GLib 2.31 against Windows XP headers yet?
(In reply to comment #4) > will it break compilation in non-mingw32 and/or Vista-or-newer environments? in short - yes c:\kde\trunk\git\dbus-src-git\dbus\dbus-sysdeps-win.c(59) : error C2084: Funktion 'void MemoryBarrier(void)' hat bereits einen Funktionsrumpf C:\Program Files\Microsoft SDKs\Windows\v7.0A\include\winnt.h(3939): Siehe vorherige Definition von 'MemoryBarrier'
(In reply to comment #6) > in short - yes We can't take this patch, then. I'm still somewhat inclined to say NOTOURBUG, and the mingw32 maintainers should add MemoryBarrier to their winnt.h. mingw-w64, which is a confusingly-named fork of mingw32 that supports both 32- and 64-bit Windows, does have MemoryBarrier. Since MemoryBarrier is an inlined compiler intrinsic, I still can't see how it can possibly affect runtime requirements, only build-time requirements? If it means you can't *compile* D-Bus unless you have either an up-to-date Windows SDK or a mingw-w64 toolchain, to be honest I'm tempted to say "get a newer Windows SDK or a mingw-w64 toolchain, then" (both appear to be free-to-download).
(In reply to comment #4) > Is this portable to compilers other than gcc? (My guess is "no".) msvc 2010 defines this function at C:\Program Files\Microsoft SDKs\Windows\v7.0A\Include\winnt.h(3939) as: FORCEINLINE VOID MemoryBarrier ( VOID ) { LONG Barrier; __asm { xchg Barrier, eax } } > If this is approximately how memory barriers are implemented in the Win32 SDK > or whatever it is that provides MemoryBarrier (as an always-inline thing), then > surely the distinction isn't between *running* D-Bus on (<=) XP or (>=) Vista, > but between compiling D-Bus on an older or newer SDK/compiler/C-runtime? it looks so http://msdn.microsoft.com/en-us/library/aa383745%28v=vs.85%29.aspx shows some plattform related defines. One can set for example _WIN32_WINNT to enable the api set for a specific os version, but there is no setting for detecting the sdk version. Also there is the _MSC_VER macro which defines the compiler/c-runtime version In the mentioned header from msvc2010 (_MSC_VER=1400), which uses windows sdk 7.0a, MemoryBarrier is defined unconditional. On msvc2008, which uses windows sdk 6.0a the inline function is also there (_MSC_VER=1600). For msvc I would say wrapping the MemoryBarrier inline definition with _MSC_VER<1400 should work like shown below: #if defined(_MSC_VER) && _MSC_VER < 1400 inline VOID MemoryBarrier (VOID) { LONG Barrier; __asm { xchg Barrier, eax } } #elif .... // gcc part __inline VOID MemoryBarrier(VOID) { LONG Barrier = 0; __asm__ __volatile__("xchgl %%eax,%0 " :"=r" (Barrier)); } #endif there is still the gcc part open.
(In reply to comment #7) > (In reply to comment #6) > > in short - yes > > We can't take this patch, then. > > I'm still somewhat inclined to say NOTOURBUG, and the mingw32 maintainers > should add MemoryBarrier to their winnt.h. mingw-w64, which is a > confusingly-named fork of mingw32 that supports both 32- and 64-bit Windows, > does have MemoryBarrier. > > Since MemoryBarrier is an inlined compiler intrinsic, I still can't see how it > can possibly affect runtime requirements, only build-time requirements? If it > means you can't *compile* D-Bus unless you have either an up-to-date Windows > SDK or a mingw-w64 toolchain, to be honest I'm tempted to say "get a newer > Windows SDK or a mingw-w64 toolchain, then" (both appear to be > free-to-download). This lead to the question - for which os and/or compiler should be dbus support available ? A dedicated compiler support needs people having a test environment for that compiler and there seems to be several compiler/sdk combinations possible to compile dbus on windows. At least we have vc and gcc based compilers. msvc 2005 is very old, msvc 2008 could not be downloaded from internet since one or two years and msvc 2010 is the recent compiler. How is the situation with mingw ? Next, what kind of cross compile options are there for dbus ?
(In reply to comment #9) > This lead to the question - for which os and/or compiler should > be dbus support available ? Well, we have active or semi-active maintainers for modern gcc + autotools on modern Linux (me, Lennart, Colin) and GNU/kFreeBSD (me + Debian kFreeBSD fans), and for whatever versions of MSVC and Windows you use (you). Everything else is best-effort - if people want their OS supported they'll have to help us. We do get contributions for Mac OS and Solaris fairly often; I believe the BSDs work fine too. Most of the time, making things work in a recent version of any popular Unix isn't that hard, so we might as well. I do tend to draw the line at Unix OSs that aren't (at least mostly) POSIX-compliant, because they've had literally a decade to get there. In particular, Interix seems to be substandard enough that supporting it would require treating it as a third major platform (Unix, Windows, Interix). As far as I'm concerned, the only purpose of having cmake in D-Bus is to be nice to MSVC++ users - everyone else can use autotools. I do think it's worth keeping cmake working on Linux, because that means I can test cmake changes that aren't Windows-specific (for instance to keep up with restructuring that happened in autotools-land), but I'm not really interested in cmake on niche Unix platforms. Regarding Windows, it'd be nice if D-Bus worked with some variant of mingw (which has the advantage of combining a Free compiler with widely-available MS runtime libraries), Cygwin (which has a significant Unix-portability layer, but can be treated as a mixture of Unix and Windows), and MSVC++ if you insist ;-) I believe all of those currently work fine. mingw and Cygwin both use gcc in a Unix-ish environment (you can expect to have enough Unix shell stuff to make autotools work), and neither needs a Windows SDK (mingw is basically a Free, reverse-engineered Windows SDK, using msvcrt.dll as its runtime library). So, it seems fine to require use of autotools, and to require a reasonably recent gcc/mingw if necessary. As far as MSVC++ is concerned, I think you get to decide what you support - choose a compiler and a Windows SDK version (preferably one that's downloadable at no cost) and declare anything older to be unsupported. For runtime requirements, the usual minimum version these days seems to be XP, or 2000 if it's easy to do? > How is the situation with mingw ? There are two major versions, mingw32 (the original, apparently rather outdated and not very well maintained) and mingw-w64 (a fork which also supports 64-bit Windows). After some recent discussion on the debian-devel mailing list, Debian is in the process of moving cross-compiled packages from mingw32 to mingw-w64. I believe Fedora has already done the same. > Next, what kind of cross compile options are there for dbus ? In principle gcc can cross-compile for any supported host architecture on any supported build architecture. I'm not sure whether dbus' cmake build system knows how to cross-compile, but to be honest I don't really care - the autotools build system does, and that's sufficient. If you're cross-compiling, then in practice you're almost certainly running gcc on Linux anyway. I run x86-64 Linux, and occasionally cross-compile dbus for 32-bit Windows using mingw-w64. Some of the tests pass under Wine, some don't (I suspect some of the tests have hidden Unix assumptions, though - do you run them on real Windows?)
(In reply to comment #10) > (In reply to comment #9) > > This lead to the question - for which os and/or compiler should > > be dbus support available ? > > Well, we have active or semi-active maintainers for modern gcc + autotools on > modern Linux (me, Lennart, Colin) and GNU/kFreeBSD (me + Debian kFreeBSD fans), > and for whatever versions of MSVC and Windows you use (you). > > Everything else is best-effort - if people want their OS supported they'll have > to help us. We do get contributions for Mac OS and Solaris fairly often; I > believe the BSDs work fine too. Most of the time, making things work in a > recent version of any popular Unix isn't that hard, so we might as well. > > I do tend to draw the line at Unix OSs that aren't (at least mostly) > POSIX-compliant, because they've had literally a decade to get there. In > particular, Interix seems to be substandard enough that supporting it would > require treating it as a third major platform (Unix, Windows, Interix). > > As far as I'm concerned, the only purpose of having cmake in D-Bus is to be > nice to MSVC++ users - everyone else can use autotools. I do think it's worth > keeping cmake working on Linux, because that means I can test cmake changes > that aren't Windows-specific (for instance to keep up with restructuring that > happened in autotools-land), but I'm not really interested in cmake on niche > Unix platforms. Just a few side note: - dbus cmake build system is recommended by the kde on windows project for msvc 2010 and mingw-w32/w64 compiler. - also using cmake on windows reduces the amount of required dependencies autotools: msys, autoconf, automake, m4,... expat, gcc, binutils, make cmake: expat, gcc, binutils, make, cmake > Regarding Windows, it'd be nice if D-Bus worked with some variant of mingw > (which has the advantage of combining a Free compiler with widely-available MS > runtime libraries), Cygwin (which has a significant Unix-portability layer, but > can be treated as a mixture of Unix and Windows), and MSVC++ if you insist ;-) > I believe all of those currently work fine. > > mingw and Cygwin both use gcc in a Unix-ish environment (you can expect to have > enough Unix shell stuff to make autotools work), and neither needs a Windows > SDK (mingw is basically a Free, reverse-engineered Windows SDK, using > msvcrt.dll as its runtime library). So, it seems fine to require use of > autotools, and to require a reasonably recent gcc/mingw if necessary. > > As far as MSVC++ is concerned, I think you get to decide what you support - > choose a compiler and a Windows SDK version (preferably one that's downloadable > at no cost) and declare anything older to be unsupported. For runtime > requirements, the usual minimum version these days seems to be XP, or 2000 if > it's easy to do? > > > How is the situation with mingw ? > > There are two major versions, mingw32 (the original, apparently rather outdated > and not very well maintained) and mingw-w64 (a fork which also supports 64-bit > Windows). After some recent discussion on the debian-devel mailing list, Debian > is in the process of moving cross-compiled packages from mingw32 to mingw-w64. > I believe Fedora has already done the same. kde on windows migrated from mingw4 to mingw32/63 this year. Okay, then we should announce the following: dbus supports Windows XP, Windows Vista and Windows 7 supported compiler/sdk are msvc 2010, mingw-w32/w64, cygwin > > > Next, what kind of cross compile options are there for dbus ? > > In principle gcc can cross-compile for any supported host architecture on any > supported build architecture. I'm not sure whether dbus' cmake build system > knows how to cross-compile, but to be honest I don't really care - the > autotools build system does, and that's sufficient. If you're cross-compiling, > then in practice you're almost certainly running gcc on Linux anyway. > > I run x86-64 Linux, and occasionally cross-compile dbus for 32-bit Windows > using mingw-w64. Some of the tests pass under Wine, some don't (I suspect some > of the tests have hidden Unix assumptions, though - do you run them on real Windows?) yes c:\>cd <build-root> c:\>set DBUS_TEST_DATA=%CD%\test\data c:\>bin\dbus-test.exe Test data in C:\kde\trunk\build\win32libs-sources\dbus-src-1.4.10-20110302\work\msvc2010-Debug-gitHEAD\test\data dbus-test: running string tests dbus-test: checking for memleaks dbus-test: running sysdeps tests dbus-test: checking for memleaks dbus-test: running data-slot tests dbus-test: checking for memleaks dbus-test: running misc tests dbus-test: checking for memleaks dbus-test: running address tests dbus-test: checking for memleaks dbus-test: running server tests dbus-test: checking for memleaks dbus-test: running object-tree tests dbus-test: checking for memleaks dbus-test: running signature tests dbus-test: checking for memleaks dbus-test: running marshalling tests dbus-test: checking for memleaks SKIP: recursive marshal tests disabled dbus-test: running byteswap tests 120 blocks swapped from order 'l' to 'B' 120 blocks swapped from order 'B' to 'l' dbus-test: checking for memleaks dbus-test: running memory tests dbus-test: checking for memleaks dbus-test: running mem-pool tests dbus-test: checking for memleaks dbus-test: running list tests dbus-test: checking for memleaks dbus-test: running marshal-validate tests dbus-test: checking for memleaks dbus-test: running message tests testing message loading: trivial example of each message type 4 test loads cumulative testing message loading: assorted arguments 124 test loads cumulative testing message loading: assorted special cases 146 test loads cumulative testing message loading: each uint32 modified 35368 test loads cumulative testing message loading: wrong body lengths 38368 test loads cumulative testing message loading: each byte modified 51547 test loads cumulative 51547 sample messages tested validity 0 seen 381 times validity 1 seen 3471 times validity 2 seen 177 times validity 4 seen 3 times validity 5 seen 3 times validity 6 seen 3 times validity 7 seen 273 times validity 8 seen 3 times validity 9 seen 15780 times validity 10 seen 189 times validity 11 seen 2727 times validity 12 seen 5718 times validity 13 seen 3960 times validity 14 seen 360 times validity 15 seen 3 times validity 16 seen 1080 times validity 17 seen 1440 times validity 18 seen 1107 times validity 19 seen 3 times validity 20 seen 1080 times validity 21 seen 7200 times validity 22 seen 3 times validity 23 seen 3 times validity 24 seen 720 times validity 25 seen 360 times validity 26 seen 1440 times validity 27 seen 720 times validity 28 seen 360 times validity 29 seen 3 times validity 30 seen 720 times validity 31 seen 3 times validity 32 seen 360 times validity 33 seen 3 times validity 34 seen 3 times validity 35 seen 14625 times validity 37 seen 6666 times validity 38 seen 2013 times validity 39 seen 15447 times validity 40 seen 1788 times validity 41 seen 8325 times validity 42 seen 3408 times validity 43 seen 4875 times validity 45 seen 3327 times validity 46 seen 7485 times validity 47 seen 1125 times validity 48 seen 3 times validity 49 seen 3 times validity 50 seen 144 times validity 51 seen 3 times validity 54 seen 12 times validity 57 seen 3 times validity -4 seen 0 times validity -2 seen 0 times validity 3 seen 0 times validity 36 seen 0 times validity 44 seen 0 times validity 52 seen 0 times validity 53 seen 0 times validity 55 seen 0 times validity 56 seen 0 times Testing valid-messages: SKIP: Could not load array-of-array-of-uint32.message, message builder language no longer supported SKIP: Could not load dict-simple.message, message builder language no longer supported SKIP: Could not load dict.message, message builder language no longer supported SKIP: Could not load emptiness.message, message builder language no longer supported SKIP: Could not load lots-of-arguments.message, message builder language no longer supported SKIP: Could not load no-padding.message, message builder language no longer supported SKIP: Could not load opposite-endian.message, message builder language no longer supported SKIP: Could not load recursive-types.message, message builder language no longer supported SKIP: Could not load simplest-manual.message, message builder language no longer supported SKIP: Could not load simplest.message, message builder language no longer supported SKIP: Could not load standard-acquire-service.message, message builder language no longer supported SKIP: Could not load standard-hello.message, message builder language no longer supported SKIP: Could not load standard-list-services.message, message builder language no longer supported SKIP: Could not load standard-service-exists.message, message builder language no longer supported SKIP: Could not load unknown-header-field.message, message builder language no longer supported Testing invalid-messages: SKIP: Could not load array-of-nil.message, message builder language no longer supported SKIP: Could not load array-with-mixed-types.message, message builder language no longer supported SKIP: Could not load bad-boolean-array.message, message builder language no longer supported SKIP: Could not load bad-boolean.message, message builder language no longer supported SKIP: Could not load bad-endian.message, message builder language no longer supported SKIP: Could not load bad-header-field-alignment.message, message builder language no longer supported boolean-has-no-value.message-raw SKIP: Could not load local-namespace.message, message builder language no longer supported SKIP: Could not load no-dot-in-name.message, message builder language no longer supported SKIP: Could not load not-nul-header-padding.message, message builder language no longer supported SKIP: Could not load overlong-name.message, message builder language no longer supported SKIP: Could not load too-little-header-padding.message, message builder language no longer supported SKIP: Could not load too-much-header-padding-by-far.message, message builder language no longer supported SKIP: Could not load too-much-header-padding.message, message builder language no longer supported SKIP: Could not load too-short-dict.message, message builder language no longer supported Testing incomplete-messages: SKIP: Could not load missing-body.message, message builder language no longer supported dbus-test: checking for memleaks dbus-test: running hash tests Computing test hash keys... ... done. dbus-test: checking for memleaks dbus-test: running spawn tests dbus-test: checking for memleaks dbus-test: running credentials tests dbus-test: checking for memleaks dbus-test: running keyring tests Using your real home directory for testing, set DBUS_TEST_HOMEDIR to avoid 1 keys in test dbus-test: checking for memleaks dbus-test: running sha tests SHA-1: H>SHS Type 1 Strings<H SHA-1: H>SHS Type 2 Strings<H SHA-1: H>SHS Type 3 Strings<H (ending tests due to Type 3 tests seen - this is normal) Passed the 229 SHA-1 tests in the test file dbus-test: checking for memleaks dbus-test: running auth tests Testing auth: anonymous-client-successful.auth-script anonymous-server-successful.auth-script cancel.auth-script client-out-of-mechanisms.auth-script external-failed.auth-script external-root.auth-script skipping unix only auth script external-silly.auth-script external-successful.auth-script extra-bytes.auth-script fail-after-n-attempts.auth-script fallback.auth-script invalid-command-client.auth-script invalid-command.auth-script invalid-hex-encoding.auth-script mechanisms.auth-script dbus-test: checking for memleaks dbus-test: completed successfully There is still a problem with session.d directory Failed to load valid file but still had memory: Failed to read directory "C:\kde\trunk\build\win32libs-sources\dbus-src-1.4.10-20110302\work\msvc2010-Debug-gitHEAD\test\data\valid-config-files\session.d": Das System kann den angegebenen Pfad nicht finden. which is fixed temporary by the following command C:\kde\trunk\build\win32libs-sources\dbus-src-1.4.10-20110302\work\msvc2010-Debug-gitHEAD>mkdir %CD%\test\data\valid-config-files\session.d C:\kde\trunk\build\win32libs-sources\dbus-src-1.4.10-20110302\work\msvc2010-Debug-gitHEAD>bin\bus-test.exe bin\bus-test.exe: Running expire list test bin\bus-test.exe: checking for memleaks bin\bus-test.exe: Running config file parser test Testing retrieving the default session service directories default service dir: C:\kde\trunk\build\win32libs-sources\dbus-src-1.4.10-20110302\work\msvc2010-Debug-gitHEAD\share/dbus-1/services default service dir: C:\Program Files\Common Files/dbus-1/services test service dir: C:\kde\trunk\build\win32libs-sources\dbus-src-1.4.10-20110302\work\msvc2010-Debug-gitHEAD\share/dbus-1/services test service dir: C:\Program Files\Common Files/dbus-1/services default system service dir skipped Testing valid files: basic.conf debug-allow-all-sha1.conf debug-allow-all.conf entities.conf incoming-limit.conf many-rules.conf Unknown username "root" on element <deny> Unknown group "bin" on element <deny> Unknown username "root" on element <deny> Unknown group "bin" on element <deny> session.conf system.conf Unknown username "root" in message bus configuration file Testing invalid files: badselinux-1.conf badselinux-2.conf circular-1.conf circular-2.conf circular-3.conf not-well-formed.conf truncated-file.conf Comparing equivalent files: basic-1.conf basic-2.conf Comparing equivalent files: entities-1.conf entities-2.conf bin\bus-test.exe: checking for memleaks bin\bus-test.exe: Running signals test bin\bus-test.exe: checking for memleaks bin\bus-test.exe: Running SHA1 connection test Using your real home directory for testing, set DBUS_TEST_HOMEDIR to avoid bin\bus-test.exe: checking for memleaks bin\bus-test.exe: Running message dispatch test TODO: testing of GetConnectionUnixUser message skipped for now TODO: testing of GetConnectionUnixProcessID message skipped for now Activating service name='org.freedesktop.DBus.TestSuiteEchoService' Successfully activated service 'org.freedesktop.DBus.TestSuiteEchoService' TODO: dispatch.c segfault_service_no_auto_start test Activating service name='org.freedesktop.DBus.TestSuiteEchoService' Successfully activated service 'org.freedesktop.DBus.TestSuiteEchoService' Activating service name='org.freedesktop.DBus.TestSuiteEchoService' Successfully activated service 'org.freedesktop.DBus.TestSuiteEchoService' Activating service name='org.freedesktop.DBus.TestSuiteEchoService' Successfully activated service 'org.freedesktop.DBus.TestSuiteEchoService' Activating service name='org.freedesktop.DBus.TestSuiteEchoService' Successfully activated service 'org.freedesktop.DBus.TestSuiteEchoService' Activating service name='org.freedesktop.DBus.TestSuiteEchoService' Successfully activated service 'org.freedesktop.DBus.TestSuiteEchoService' Activating service name='org.freedesktop.DBus.TestSuiteEchoService' Successfully activated service 'org.freedesktop.DBus.TestSuiteEchoService' Activating service name='org.freedesktop.DBus.TestSuiteEchoService' Successfully activated service 'org.freedesktop.DBus.TestSuiteEchoService' Activating service name='org.freedesktop.DBus.TestSuiteEchoService' Successfully activated service 'org.freedesktop.DBus.TestSuiteEchoService' Activating service name='org.freedesktop.DBus.TestSuiteEchoService' Successfully activated service 'org.freedesktop.DBus.TestSuiteEchoService' Activating service name='org.freedesktop.DBus.TestSuiteEchoService' Successfully activated service 'org.freedesktop.DBus.TestSuiteEchoService' Activating service name='org.freedesktop.DBus.TestSuiteEchoService' Successfully activated service 'org.freedesktop.DBus.TestSuiteEchoService' Activating service name='org.freedesktop.DBus.TestSuiteEchoService' Successfully activated service 'org.freedesktop.DBus.TestSuiteEchoService' Activating service name='org.freedesktop.DBus.TestSuiteEchoService' Successfully activated service 'org.freedesktop.DBus.TestSuiteEchoService' Activating service name='org.freedesktop.DBus.TestSuiteEchoService' Successfully activated service 'org.freedesktop.DBus.TestSuiteEchoService' Activating service name='org.freedesktop.DBus.TestSuiteEchoService' Successfully activated service 'org.freedesktop.DBus.TestSuiteEchoService' Activating service name='org.freedesktop.DBus.TestSuiteEchoService' Successfully activated service 'org.freedesktop.DBus.TestSuiteEchoService' Activating service name='org.freedesktop.DBus.TestSuiteEchoService' Successfully activated service 'org.freedesktop.DBus.TestSuiteEchoService' Activating service name='org.freedesktop.DBus.TestSuiteEchoService' Successfully activated service 'org.freedesktop.DBus.TestSuiteEchoService' Activating service name='org.freedesktop.DBus.TestSuiteEchoService' Successfully activated service 'org.freedesktop.DBus.TestSuiteEchoService' Activating service name='org.freedesktop.DBus.TestSuiteEchoService' Successfully activated service 'org.freedesktop.DBus.TestSuiteEchoService' Activating service name='org.freedesktop.DBus.TestSuiteEchoService' Successfully activated service 'org.freedesktop.DBus.TestSuiteEchoService' Activating service name='org.freedesktop.DBus.TestSuiteEchoService' Successfully activated service 'org.freedesktop.DBus.TestSuiteEchoService' Activating service name='org.freedesktop.DBus.TestSuiteEchoService' Successfully activated service 'org.freedesktop.DBus.TestSuiteEchoService' Activating service name='org.freedesktop.DBus.TestSuiteEchoService' Successfully activated service 'org.freedesktop.DBus.TestSuiteEchoService' Activating service name='org.freedesktop.DBus.TestSuiteEchoService' Successfully activated service 'org.freedesktop.DBus.TestSuiteEchoService' Activating service name='org.freedesktop.DBus.TestSuiteEchoService' Successfully activated service 'org.freedesktop.DBus.TestSuiteEchoService' Activating service name='org.freedesktop.DBus.TestSuiteEchoService' Successfully activated service 'org.freedesktop.DBus.TestSuiteEchoService' Activating service name='org.freedesktop.DBus.TestSuiteEchoService' Successfully activated service 'org.freedesktop.DBus.TestSuiteEchoService' Activating service name='org.freedesktop.DBus.TestSuiteEchoService' Successfully activated service 'org.freedesktop.DBus.TestSuiteEchoService' Activating service name='org.freedesktop.DBus.TestSuiteEchoService' Successfully activated service 'org.freedesktop.DBus.TestSuiteEchoService' Activating service name='org.freedesktop.DBus.TestSuiteEchoService' Successfully activated service 'org.freedesktop.DBus.TestSuiteEchoService' Activating service name='org.freedesktop.DBus.TestSuiteEchoService' Successfully activated service 'org.freedesktop.DBus.TestSuiteEchoService' Activating service name='org.freedesktop.DBus.TestSuiteEchoService' Successfully activated service 'org.freedesktop.DBus.TestSuiteEchoService' Activating service name='org.freedesktop.DBus.TestSuiteEchoService' Successfully activated service 'org.freedesktop.DBus.TestSuiteEchoService' TODO: dispatch.c segfault_service_auto_start test Activating service name='org.freedesktop.DBus.TestSuiteEchoService' Successfully activated service 'org.freedesktop.DBus.TestSuiteEchoService' Echo service echoed string: "Test echo message" Sending HelloFromSelf Sent HelloFromSelf Received the HelloFromSelf message Reply from HelloFromSelf received Activating service name='org.freedesktop.DBus.TestSuiteShellEchoServiceSuccess' Successfully activated service 'org.freedesktop.DBus.TestSuiteShellEchoServiceSuccess' Shell echo service echoed the command line Info: Launch helper activation tests skipped because launch-helper is not supported yet bin\bus-test.exe: checking for memleaks bin\bus-test.exe: Running service files reloading test bin\bus-test.exe: checking for memleaks bin\bus-test.exe: Success
mingw4 isn't a supported platform on windows. Compilers are supported because people use them in their daily work and are able and willing to fix bugs and provide patches. If people need to have support for a dedicated compiler they have to care about this compiler in term of bug fixing and providing working patches.
*** Bug 44431 has been marked as a duplicate of this bug. ***
I'm reopening this because as much as it's not really our problem, mingw.org doesn't show any signs of fixing this, and everyone[1][2][3][4] keeps hacking around it using cargo-culted patches that will break MSVC and mingw-w64. A note on terminology to be completely clear, since it's ridiculously confusing: MinGW (mingw.org, current version "MinGW 4", formerly MinGW32, GNU tuple i586-pc-mingw32), is a build environment and toolchain targeting 32-bit Windows, either compiling under Windows or cross-compiling from Unix. It used to be shipped in Debian as gcc-mingw32. MinGW-w64 (mingw-w64.sourceforge.net, GNU tuples i686-w64-mingw32 for 32-bit and x86_64-w64-mingw32 for 64-bit) is a fork of MinGW targeting both 32- and 64-bit Windows. Its GNU tuples seem to have been carefully chosen to cause the maximum possible amount of confusion, but it also seems to work better than MinGW. It's what is now shipped in Debian, e.g. to compile Wine. Ralf is D-Bus' Windows maintainer. I believe the configuration he supports is CMake + MSVC. As a result, we will not knowingly apply patches that break MSVC, and if we accidentally break this configuration, Ralf will hopefully catch it eventually. I occasionally test that D-Bus cross-compiles with Autotools and MinGW-w64 on Debian - some of the tests even work under Wine in this configuration - so I have an interest in making this configuration work. So, we will not knowingly apply patches that break Autotools + MinGW-w64, and if we accidentally break this configuration, we'll hopefully catch it eventually. As far as I know, no D-Bus maintainer does systematic testing with MinGW from mingw.org, but it seems to be rather popular with people who cross-compile D-Bus anyway. If you (for any value of "you") would like MinGW to be a supported platform for D-Bus, please volunteer to be its maintainer, test it on a regular basis, and provide patches that aren't going to break our other platforms (i.e. respond to review feedback and suggest/test alternatives, rather than advocating use of patches that have already been rejected). [1] https://lists.gnu.org/archive/html/mingw-cross-env-list/2011-09/msg00033.html [2] http://lists.freedesktop.org/archives/dbus/2012-June/015158.html [3] http://poquitopicante.blogspot.co.uk/2012/07/building-dbus-python-on-windows-with.html [4] https://bugs.freedesktop.org/show_bug.cgi?id=44431
Created attachment 65342 [details] [review] Use InterlockedIncrement to get a full memory barrier on Windows
(In reply to comment #15) > Created attachment 65342 [details] [review] > Use InterlockedIncrement to get a full memory barrier on Windows There's my proposal. Note that I have not run it... but it seems better than having a patch floating around that's known to break our supported targets and hence will not be accepted, but everyone who likes mingw passes it around on the grapevine and applies it anyway. Code review would be much appreciated. When I compile with mingw-w64 and disassemble the resulting binary (objdump -d dbus/.libs/libdbus-1-3.dll) I get this implementation of _dbus_atomic_get: 66092210 <__dbus_atomic_get>: 66092210: 83 ec 10 sub $0x10,%esp 66092213: b8 01 00 00 00 mov $0x1,%eax 66092218: c7 44 24 0c 00 00 00 movl $0x0,0xc(%esp) 6609221f: 00 66092220: f0 0f c1 44 24 0c lock xadd %eax,0xc(%esp) 66092226: 8b 44 24 14 mov 0x14(%esp),%eax 6609222a: 8b 00 mov (%eax),%eax 6609222c: 83 c4 10 add $0x10,%esp 6609222f: c3 ret I don't speak fluent x86 assembler, but I believe the "lock xadd" is the memory barrier that we wanted, and the two mov instructions immediately following it are the "get" operation (the first one gets the DBusAtomic * from the stack, the second dereferences the pointer and puts the result in register EAX to be returned). Someone who cares about MSVC (Ralf?), please compile and test this with MSVC, disassemble its version of _dbus_atomic_get and check that it does roughly the right thing. Someone who cares about mingw.org's mingw (Mat? Siraj? Mark?), please compile and test this with mingw, disassemble *its* version of _dbus_atomic_get and check that *it* does the right thing.
Comment on attachment 65342 [details] [review] Use InterlockedIncrement to get a full memory barrier on Windows See no reason why this should not work A cosmetic optimization may be to use InterlockedExchange http://msdn.microsoft.com/en-us/library/windows/desktop/ms683590%28v=vs.85%29.aspx instead of InterlockedIncrement because the original MemoryBarrier() implementation uses an exchange statement (mentioned in this thread). In this case the patch need to be updated with ... - InterlockedIncrement (&dummy); + InterlockedExchange (&dummy, 1); ...
(In reply to comment #17) > A cosmetic optimization may be to use InterlockedExchange > instead of InterlockedIncrement because > the original MemoryBarrier() implementation uses an exchange statement Sure, why not. On mingw-w64 that gets compiled to 66092210 <__dbus_atomic_get>: 66092210: 83 ec 10 sub $0x10,%esp 66092213: b8 01 00 00 00 mov $0x1,%eax 66092218: c7 44 24 0c 00 00 00 movl $0x0,0xc(%esp) 6609221f: 00 66092220: f0 87 44 24 0c lock xchg %eax,0xc(%esp) 66092225: 8b 44 24 14 mov 0x14(%esp),%eax 66092229: 8b 00 mov (%eax),%eax 6609222b: 83 c4 10 add $0x10,%esp 6609222e: c3 ret 6609222f: 90 nop which, again, looks to me like a memory barrier followed by a "get", as desired. I'll attach the alternative patch. Neither patch can be applied without review and testing. Please compile, disassemble, test, review?
Created attachment 65504 [details] [review] [alternative] Use InterlockedExchange to get a full memory barrier on Windows The same as the other patch, but with InterlockedExchange instead, since both mingw-w64 and MSVC appear to implement MemoryBarrier() with an xchg instruction.
(In reply to comment #18) > (In reply to comment #17) > > A cosmetic optimization may be to use InterlockedExchange > > instead of InterlockedIncrement because > > the original MemoryBarrier() implementation uses an exchange statement > > Sure, why not. On mingw-w64 that gets compiled to > > 66092210 <__dbus_atomic_get>: > 66092210: 83 ec 10 sub $0x10,%esp > 66092213: b8 01 00 00 00 mov $0x1,%eax > 66092218: c7 44 24 0c 00 00 00 movl $0x0,0xc(%esp) > 6609221f: 00 > 66092220: f0 87 44 24 0c lock xchg %eax,0xc(%esp) > 66092225: 8b 44 24 14 mov 0x14(%esp),%eax > 66092229: 8b 00 mov (%eax),%eax > 6609222b: 83 c4 10 add $0x10,%esp > 6609222e: c3 ret > 6609222f: 90 nop > > which, again, looks to me like a memory barrier followed by a "get", as > desired. > > I'll attach the alternative patch. > > Neither patch can be applied without review and testing. Please compile, > disassemble, test, review? here is a disassemble of the related msvc compile. Interlocked... functions are located in kernel32.dll and are not inlined. __dbus_atomic_inc: 00000000: 8B 44 24 04 mov eax,dword ptr [esp+4] 00000004: 50 push eax 00000005: FF 15 00 00 00 00 call dword ptr [__imp__InterlockedIncrement@4] 0000000B: 48 dec eax 0000000C: C3 ret __dbus_atomic_dec: 00000000: 8B 44 24 04 mov eax,dword ptr [esp+4] 00000004: 50 push eax 00000005: FF 15 00 00 00 00 call dword ptr [__imp__InterlockedDecrement@4] 0000000B: 40 inc eax 0000000C: C3 ret __dbus_atomic_get: 00000000: 51 push ecx 00000001: 6A 01 push 1 00000003: 8D 44 24 04 lea eax,[esp+4] 00000007: 50 push eax 00000008: C7 44 24 08 00 00 mov dword ptr [esp+8],0 00 00 00000010: FF 15 00 00 00 00 call dword ptr [__imp__InterlockedExchange@8] 00000016: 8B 4C 24 08 mov ecx,dword ptr [esp+8] 0000001A: 8B 01 mov eax,dword ptr [ecx] 0000001C: 59 pop ecx 0000001D: C3 ret The call to 00000010: FF 15 00 00 00 00 call dword ptr [__imp__InterlockedExchange@8] is the memory barrier and 0000001A: 8B 01 mov eax,dword ptr [ecx] is the get statement. According to http://www.installsetupconfig.com/win32programming/threadprocesssynchronizationapis11_40.html there is "... The InterlockedExchange() function generates a full memory barrier (or fence) and performs the exchange operation. This ensures the strict memory access ordering that is necessary,..." so this implementation looks good to me.
Fixed in git for 1.7.0. I'm not going to go applying patches to the stable branch in code I don't compile to support toolchains none of the dbus maintainers use; but if anyone else wants to cherry-pick this onto dbus-1.6 after appropriate testing, go for it.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.