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

[John Ralls <jralls ceridwen fremont ca us>]

On Feb 20, 2010, at 12:40 PM, Vincent Lucarelli wrote:

> jhbuildrc disables ige-mac-integration on x86_64, but gnucash failed to configure without it.
> 
> I cloned git://github.com/afb/ige-mac-integration.git and installed it to get the build to succeed.
> I'm not sure who has the latest cocoa ige-mac-integration or how incomplete it is, but at least
> gnucash was built.
> 
> When I went to run it, it got
> 
> main: Error on gbr_init: Binreloc found that the bundle is not an app bundle
> dyld: lazy symbol binding failed: Symbol not found: _cairo_quartz_font_face_create_for_atsu_font_id
>  Referenced from: /opt/gtk/lib/libpangocairo-1.0.0.dylib
>  Expected in: flat namespace
> 
> dyld: Symbol not found: _cairo_quartz_font_face_create_for_atsu_font_id
>  Referenced from: /opt/gtk/lib/libpangocairo-1.0.0.dylib
>  Expected in: flat namespace
> 
> Trace/BPT trap
> 
> Any ideas?  Is this configure issue or bug in cairo?
> 

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.

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

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.

Regards,
John Ralls