commit 78fea12afc5f0db5a137d0766e92994232f60a78

Mike Alexander mta at
Sat Dec 13 02:39:09 EST 2014

--On December 11, 2014 at 8:31:03 PM -0800 John Ralls 
<jralls at> wrote:

> Thanks for reverting.

No problem, I shouldn't have committed it in the first place.

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

I do use MacPorts and I see that it has a really weird patch to Glib's 
configure file which affects this area.  I need to figure out what they 
think they are doing and what effect it may be having on this problem. 
MacPorts essentially ignores and patches configure, which 
makes it harder to understand what is going on.

For  the moment I patched Apple's headers to look at __LP64__ when 
defining the int64 types and this works.  It's obviously not a 
permanent solution.


More information about the gnucash-devel mailing list