commit 78fea12afc5f0db5a137d0766e92994232f60a78

John Ralls jralls at
Thu Dec 11 14:37:19 EST 2014

> commit 78fea12afc5f0db5a137d0766e92994232f60a78
> Author: Mike Alexander <mta at>
> Date:   Wed Dec 10 18:40:13 2014 -0500
>    Some type mismatch fixes to make it build with clang in MacOSX Mavericks.
>    These may not be the best fixes, but they make things build again with
>    XCode 6.1.1 in MacOSX 10.9.5.
> Summary of changes:
> gnucash.xcodeproj/project.pbxproj        | 24 ++++++++++++++----------
> src/bin/                   |  6 ++----
> src/engine/test-core/test-engine-stuff.c | 12 ++++++------
> src/libqof/qof/gnc-int128.hpp            |  2 ++
> src/libqof/qof/gnc-numeric.cpp           |  2 +-
> src/libqof/qof/kvp_frame.cpp             |  6 +++---
> 6 files changed, 28 insertions(+), 24 deletions(-)


Please ask on the list or file a bug before making changes to the new code. Bear in mind that I’m developing in OS X too and using Xcode tools daily though not the IDE, so problems you’re encountering are perhaps not so much related to Xcode as to building 64-bit, or perhaps to a warning that you’ve set that I haven’t. GC built fine for me before your changes with Xcode 6.1.1. I’m also testing this on Debian Wheezy and Jessie, Alex is testing on F19 and F20, and the build VM tests Win32. All compiled correctly without your changes.

Regarding standard library macros (e.g. PRIu64) vs. Glib macros (G_GINT64_FORMAT) and types (e.g. int64_t vs. gint64), maybe you didn’t register the discussion early last year [1] that kicked off the C++ development: We’re moving away from Glib, and it shouldn’t be used in new code. We need to figure out how to tune your development environment either via configure or Xcode so that it works with the standard library macros; it might be as simple as configuring std=C++11 in the Xcode IDE.

John Ralls

[1] The thread starts with

More information about the gnucash-devel mailing list