commit 78fea12afc5f0db5a137d0766e92994232f60a78

Mike Alexander mta at
Thu Dec 11 18:20:53 EST 2014

--On December 11, 2014 at 11:37:19 AM -0800 John Ralls 
<jralls at> wrote:

> 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.

Sorry about that, I've reverted that commit.  I should have cleared it 

I don't use the IDE to build, I never have done so.  I build the X 
Window version using the same automake tools as everyone else.  I only 
use the IDE to debug GnuCash, not build it.  I didn't change anything 
in configure or the makefiles related to warnings or the C++ standard 
level.  I do configure with --enable-compile-warnings=yes, but removing 
that didn't change anything since these errors are not warnings.

The problem I was having is because there is a difference between 
gint64 and int64_t which causes clang++ to not consider them to be 
interchangeable.  It appears that if __LP64__ is defined Glib declares 
gint64 as "typedef signed long" while int64_t is declared 
unconditionally as "typedef long long".  It's correct that clang 
doesn't consider these equivalent, although they are both 64 bit 
integers in that environment.  Why is this affecting me and not others? 
Am I the only one building in a 64 bit environment?

This is the first time I've taken a look at the C++ work so far, and 
I'm happy with what I see.  It looks quite good and I'll try to help 
without causing too much grief.


More information about the gnucash-devel mailing list