> On Dec 12, 2014, at 11:39 PM, Mike Alexander <[email protected]> wrote: > > --On December 11, 2014 at 8:31:03 PM -0800 John Ralls <[email protected]> > 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.
I think patching Glib is more appropriate. https://bugzilla.gnome.org/show_bug.cgi?id=741488 has the patch if you want to use it. It took an extra day thanks to Guile not building with the 10.10 SDK. That’s http://debbugs.gnu.org/cgi/bugreport.cgi?bug=19372. Regards, John Ralls _______________________________________________ gnucash-devel mailing list [email protected] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
