Skip to content

GitLab

D
dbus
Switch branch/tag
  1. 30 Jun, 2014 1 commit
  3. 10 Jun, 2014 1 commit
  5. 05 Jun, 2014 1 commit
  7. 30 Apr, 2014 2 commits
  9. 27 Jan, 2014 1 commit
  11. 20 Jan, 2014 2 commits
  13. 06 Jan, 2014 3 commits
  15. 27 Nov, 2013 1 commit
  17. 01 Nov, 2013 5 commits
  19. 10 Oct, 2013 1 commit
  21. 09 Oct, 2013 2 commits
  23. 08 Oct, 2013 4 commits
  25. 16 Sep, 2013 2 commits
    • Simon McVittie's avatar
      Remove support for platforms with no 64-bit integer type · b47d5062
      Simon McVittie authored 
      This has been a soft requirement since 1.5.0; anyone on such platforms
would have had to configure --without-64-bit, provoking a warning that
instructed them to report a D-Bus bug with details of their platform.
Nobody has done so, so if anyone still lacks a 64-bit integer type,
they're on their own.

(Also, I tried the build with --without-64-bit and it's full of
fatal compiler warnings, so it's not clear that we're actually
losing anything by removing this "feature".)

Bug: https://bugs.freedesktop.org/show_bug.cgi?id=65429Reviewed-by: default avatarChengwei Yang <chengwei.yang@intel.com>
      b47d5062
    • Simon McVittie's avatar
      dbus-sysdeps-win: don't include wspiapi.h · 3b9c2817
      Simon McVittie authored 
      This block provoked a warning on mingw-w64 because we were redefining
_inline. According to Ralf's research, it was introduced in 452ff68a:
Windows 2000 doesn't have getaddrinfo and related functions in
ws2tcpip.h, but does have a shim implementation in wspiapi.h.

At the time of 452ff68a, mingw32 didn't have wspiapi.h, so it's unclear
why there was a __GNUC__ code path here. The "#define _inline" on that
code path looks likely to be some sort of workaround for a faulty version
of wspiapi.h? Current mingw-w64 does have wspiapi.h, so we enter the
__GNUC__ code path and get the redefinition.

dbus no longer supports Windows 2000, so we no longer need wspiapi.h
at all, and can rely on XP or later. (Ralf's policy is to only support
versions of Windows that are still supported by Microsoft, and Windows 2000
reached the end of its life-cycle in 2010.)

Bug: https://bugs.freedesktop.org/show_bug.cgi?id=68852
Reviewed-by: Ralf Habacker
      3b9c2817
  27. 13 Sep, 2013 2 commits
  29. 05 Sep, 2013 2 commits
  31. 03 Sep, 2013 1 commit
    • Simon McVittie's avatar
      Tests: allow dbus-glib to be replaced with use of libdbus-internal · 30e7a813
      Simon McVittie authored 
      We only use dbus-glib for its main loop; within dbus, DBusLoop is
available as an alternative, although it isn't thread-safe and
isn't public API.

For tests that otherwise only use libdbus public API, it's desirable to
be able to avoid DBusLoop, so we can run them against an installed
libdbus as an integration test. However, if we don't have dbus-glib,
we're going to have to use an in-tree main loop, which might as well
be DBusLoop.

The major disadvantage of using dbus-glib is that it isn't safe to
link both dbus-1 and dbus-internal at the same time. This is awkward
for a future test case that wants to use _dbus_getsid() in dbus-daemon.c,
but only on Windows (fd.o #54445). If we use the same API wrapper around
both dbus-glib and DBusLoop, we can compile that test against dbus-glib
or against DBusLoop, depending on the platform.

Bug: https://bugs.freedesktop.org/show_bug.cgi?id=68852Reviewed-by: Ralf Habacker's avatarRalf Habacker <ralf.habacker@freenet.de>
      30e7a813
  33. 22 Aug, 2013 1 commit
  35. 28 Jun, 2013 2 commits
  37. 25 Jun, 2013 1 commit
  39. 13 Jun, 2013 1 commit
  41. 12 Jun, 2013 3 commits
  43. 06 Jun, 2013 1 commit