1. 19 Nov, 2015 1 commit
  2. 18 Nov, 2015 1 commit
    • Heinrich Fink's avatar
      glib: Don't store CF run loop to avoid racy cleanup · e75ddb00
      Heinrich Fink authored and Sebastian Dröge's avatar Sebastian Dröge committed
      After polling for file descriptors, the Cocoa select thread did wake up
      the main run loop instance that has been stored in a static variable.
      This variable might have already been set to NULL by
      g_main_context_release, resulting in a segfault of CFRunLoopWakeUp. This
      race is fixed by this commit by simply not storing the main run loop in
      a variable, but instead calling CFRunLoopGetMain locally where needed.
      Within a single process, the main run loop is always the same, and
      always accessible. It is therefore not necessary anyway to remember the
      run loop instance when acquiring the context.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=758285
      e75ddb00
  3. 17 Nov, 2015 3 commits
  4. 13 Nov, 2015 1 commit
  5. 11 Nov, 2015 3 commits
  6. 07 Nov, 2015 1 commit
  7. 04 Nov, 2015 1 commit
  8. 03 Nov, 2015 4 commits
  9. 02 Nov, 2015 4 commits
  10. 30 Oct, 2015 1 commit
    • Heinrich Fink's avatar
      Use xcodebuild to get 'latest' SDK path on OSX · c5020a56
      Heinrich Fink authored and Sebastian Dröge's avatar Sebastian Dröge committed
      By default, we are now always using the 'latest' SDK, as returned by the
      xcodebuild command line tool, i.e. no hard-coded SDK paths are used by
      cerbero anymore. It is still possible to ask for a specific SDK version,
      by setting 'osx_target_sdk_version' in config (e.g. setting it to
      '10.10' to force compilation against the 10.10 SDK). Requesting an SDK
      version via osx_target_sdk_version that doesn't exist on the system will
      error out.
      
      Fixes https://bugzilla.gnome.org/show_bug.cgi?id=757357
      c5020a56
  11. 28 Oct, 2015 1 commit
  12. 27 Oct, 2015 1 commit
  13. 26 Oct, 2015 1 commit
    • George Kiagiadakis's avatar
      spandsp: fix dllexport/dllimport usage on windows · 896b3fcf
      George Kiagiadakis authored
      LIBSPANDSP_EXPORTS must only be defined while building libspandsp,
      otherwise code that uses spandsp symbols will be using them with
      the dllexport attribute and the binaries will probably fail at runtime.
      
      The change in config_sh is required because we patch the Makefile.am,
      so automake needs to run again, and while "make" will detect that,
      the code in the tarball is configured to run "automake-1.13", which
      will fail on most systems nowadays. Calling autogen.sh again ensures
      that we call the correct automake.
      896b3fcf
  14. 25 Oct, 2015 2 commits
  15. 24 Oct, 2015 3 commits
  16. 23 Oct, 2015 1 commit
  17. 22 Oct, 2015 2 commits
  18. 20 Oct, 2015 7 commits
  19. 13 Oct, 2015 2 commits