How about "why are you wasting time building Gnucash for 64-bit"? There is absolutely zero advantage to it, and as you are finding, quite a few disadvantages.
Fair point. I originally had a macports installation of gimp and decided recently to move from Quicken
to gnucash and so used macports to add it. I liked macports better than fink, but after some trouble
with gnucash, started looking for something else and found jhbuild.
Not knowing all the implications of setting setup_sdk(target="10.6", sdk_version="10.6", architectures=["x86_64"])
in my rc file, I started the build and ran into this trouble. I guess my point is that for someone
not familiar with all 68 dependancies for gnucash and the status of Apple's interfaces, a reasonable
thought is that 64-bit builds will work.
Mac integration is currently written in Carbon, which doesn't support 64-bit. Paul Davis, the Ardour dev, has provided a Cocoa implementation which I'm working on generalizing, which when I get it working should solve several integration problems *and* work for 64-bit. That's a few weeks away.
The Cairo and Pango issues revolve around the transition from ATSUI to CoreText. Apple didn't do a very good job there, because CoreText wasn't a public API in 10.4, but ATSUI doesn't support 64-bit. This makes it a bit challenging to create a build setup which supports both Tiger and 64-bit Snow Leopard. Since there's no real benefit to 64-bit, the default right now for all of Gtk-OSX is 32-bit. (One might be able to show a 64-bit advantage for The GIMP. Fortunately, those guys are on the ball and are working on their own OSX portability mods, so we don't have to worry about it.)
Some obvious issues with the 32-bit build of pango on Snow Leopard from my macport installation (like making the "fi" ligature display
as the dagger symbol) affect both gimp and gnucash. Because of the long line of dependencies for an application and the
need/desire to support several generations of the OS, it can take a long while for an application to be usable on a new Mac OS release.
Given my new dependence on gnucash and gimp, I'm trying to find a place to help out and reduce the time for these applications
to be really usable on Snow Leopard. I started looking into your suggestion of figuring out how to replace the dbus interface. It doesn't
seem to be the highest priority, but I think I can make progress there.
Is your mode of operation to develop OS X specific patches and try to get them incorporated upstream?
More specifically, though, when you get one of those "Symbol not found ... Expected in flat namespace" errors, you can almost always look further up the compile output and find something like "image found, wrong architecture" for the library that should be supplying the missing symbols. You then have to study the compilation of that library to understand why it didn't build for the architecture in question. One important thing to keep in mind is that jhbuild wasn't designed with Apple's fat dylib architecture in mind, so if you're
trying to replace, say, an i386 build with an x86_64 build in the same checkoutroot and prefix, jhbuild may decline to rebuild everything because it doesn't realize that the two are incompatible.
I'm trying a clean 32-build to see how that goes. Next, I'll repeat the 64-bit build and see if I can find the
earlier indication that something went wrong.
