1. 29 Jun, 2016 5 commits
  2. 28 Jun, 2016 3 commits
  3. 25 Jun, 2016 1 commit
  4. 24 Jun, 2016 2 commits
  5. 23 Jun, 2016 1 commit
    • Allison Karlitskaya's avatar
      tests: fix uint64 argument to g_object_set() call · 9bb2499c
      Allison Karlitskaya authored
      5cea1c86 introduced accessors for 64bit
      ints to gsettings, at which point the testcases were expanded.
      
      Unfortunately, the expanded tests contained a bug: integer constants
      passed to g_object_set() for a 64-bit property need an up-cast.  Add
      that now.
      
      Problem found by Iain Lane.
      9bb2499c
  6. 22 Jun, 2016 1 commit
  7. 21 Jun, 2016 1 commit
  8. 20 Jun, 2016 4 commits
    • Allison Karlitskaya's avatar
      build: simplify dtrace configuration · 7563ab47
      Allison Karlitskaya authored
      The ability to pass libtool via $(CC) to dtrace and have it respect this
      appears to be a feature that is only present in the systemtap version of
      the tool.  In particular, FreeBSD (which seems to be using a copy of the
      tool from Solaris) doesn't support this.
      
      The result is that, with $(CC) ignored, and a .lo file specified in -o,
      we get an ELF written to the .lo.
      
      Instead of trying to have dtrace run libtool we can have libtool run
      dtrace.  dtrace is really just a compiler that produces an object file
      here, and it even understands -o, so libtool can make the appropriate
      adjustments.
      
      There appears to be some prior art for this approach.  A quick search
      shows that at least QEMU is using this approach.  It also appears to
      work on Linux with systemtap's dtrace and on FreeBSD.
      
      This may regress cross-compilation because the dtrace command will have
      no way of knowing which compiler we intend for it to use to produce the
      object file.  I say "may" because I don't know if dtrace ever worked in
      the first place under cross-compilation.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=725902
      7563ab47
    • Matthias Clasen's avatar
      2.49.2 · b990acf7
      Matthias Clasen authored
      b990acf7
    • Matthias Clasen's avatar
      Updates · 26e07869
      Matthias Clasen authored
      26e07869
    • Chun-wei Fan's avatar
      Visual Studio builds: Fix .pc generation · bbf07fb1
      Chun-wei Fan authored
      The previous update did not account for when no exec_prefix is spcified,
      so update that, and use ${prefix} by default.  Clean up a bit as well.
      bbf07fb1
  9. 19 Jun, 2016 1 commit
  10. 16 Jun, 2016 2 commits
  11. 15 Jun, 2016 11 commits
  12. 07 Jun, 2016 3 commits
    • Christoph Reiter's avatar
      Partly revert "gio: Add filename type annotations" · 9ec74d20
      Christoph Reiter authored
      Revert all annotation changes for environment variables and command line
      arguments.
      
      See commit f8189ddf.
      9ec74d20
    • Christoph Reiter's avatar
      Partly revert "glib: Add filename type annotations" · c9dd2049
      Christoph Reiter authored
      Revert all annotation changes for environment variables and command line
      arguments.
      
      See commit 41013a01.
      c9dd2049
    • Chun-wei Fan's avatar
      config.h.win32.in: Always define HAVE_LONG_LONG · 9198f19d
      Chun-wei Fan authored
      Visual Studio actually supports long long types, but HAVE_LONG_LONG is
      undefined for Visual Studio builds, likely due to issues in previous
      gnulib code for printf functionality, that was bundled with GLib.
      
      Since gnulib has much better support with Visual Studio nowadays (which we
      updated the related code to last October), and HAVE_LONG_LONG being undefined
      actually causes issues in Visual Studio builds, which was demonstrated with
      the type-test test program in tests/, we should always define HAVE_LONG_LONG
      in config.h.win32.in.
      
      Thanks to Paolo Borelli for the heads up on the issue.
      9198f19d
  13. 04 Jun, 2016 4 commits
  14. 03 Jun, 2016 1 commit