--On December 11, 2014 at 8:31:03 PM -0800 John Ralls
<jra...@ceridwen.us> 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 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.
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 configure.ac 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.
Mike
_______________________________________________
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
