Re: [Gtk-osx-devs] Third and Forth problem with gnucash on 10.6

[John Ralls <jralls ceridwen us>]

On Feb 21, 2010, at 6:30 PM, Vincent Lucarelli wrote:

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.

You do know that I maintain OSX App bundles for Gnucash, right? The download link for the 2.2.9 stable release is on the website (http:www.gnucash.org). Very highly recommended for production use. You can help the project by testing the unstable release on a copy of your data, and of course you will need to get svn going if you're going to write patches.

The project wiki (for which http://gtk-osx.sourceforge.net provides an easy entry point) has information about some of the issues one encounters building gtk-osx projects in general, including a page on 64-bit.

Do in particular be careful to keep your MacPorts and Gtk-OSX stuff separate (paying particular attention to the various paths set in environment variables). Cross-pollenating between the two has been known to make a mess.

There are some significant issues with both Pango and Cairo over the transition from ATSUI to CoreText, particularly with Pango.

We (meaning Paul Davis of Ardour and I along with a few less-consistent kvetchers) have badgered one of the Gtk+ core devs, 

Kristian Reitveld, into doing some work on the quartz implementations and getting patches incorporated. So, yes, the goal is to move everything that makes sense into the appropriate library. In the meantime, Gtk-OSX can provide add-on libraries like ige-mac-integration and patchfiles which are automatically applied by jhbuild to tarballs. Unfortunately, jhbuild has no provision for automatically patching VCS checkouts (which makes sense, because the risk is quite high that a patch won't apply cleanly against a

checkout unless the patch is in some dusty corner of the code).

Regards,

John Ralls