commit 78fea12afc5f0db5a137d0766e92994232f60a78

[John Ralls]

> On Dec 11, 2014, at 3:20 PM, Mike Alexander <mta at umich.edu> wrote:
> 
> --On December 11, 2014 at 11:37:19 AM -0800 John Ralls <jralls at ceridwen.us> 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 first.
> 
> 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.
> 

Mike,

Thanks for reverting.

You may well be the only one who's building 64-bit on a mac. I think pretty much everyone does on Linux, but Linux seems to declare int64_t conditionally as long on 64-bit processors while, as you noted, Apple defines it unconditionally as long long. No doubt they did so to make their lives easier when they were doing the transition from Intel Core2 to Core2 duo a few years ago and saw no reason to change once the transition was complete. Glib's configure ignores C defines entirely and uses AC_CHECK_SIZEOF(long) and AC_CHECK_SIZEOF(long long) to decide; if $ac_cv_sizeof_long == 8 then it wins.

The simplest fix would be to patch glib's configure.ac to let $ac_cv_sizeof_long_long win if building on darwin, but I don't know if that will fly with the Glib crew. I'll file a bug tomorrow and see how it goes. In the meantime you can patch it locally on your machine. You're using MacPorts IIRC. They might be more accepting of that patch if Glib won't take it.

Regards,
John Ralls