Building Mac OS X GnuCash and run-time failures -- file: "libgncmod-engine", message: "file not found"

Wed Mar 18 18:22:50 EDT 2015

> On Mar 17, 2015, at 9:55 PM, Jeff Kletsky <gnucash at allycomm.com> wrote:
> 
> Well, it's been an interesting journey trying to get GnuCash to build and run under Mac OS X.
> (Yes, I need to do this.)
> 
> First off, thanks to John Ralls for quickly merging in my patch to use the current repository for xmlsec!
> 
> For anyone trying to do this on their own, this is what I've found:
> 
> I'm using a "throw-away" account just in case the build/install process pollutes the environment in some unexpected way. So far, it looks like the only directories touched are in ~/.local (don't delete as other apps/processes use it) and in ~/gnucash-on-osx and ~/gtk -- this is a *good* thing, in my opinion. Thanks for that in the build scripts!
> 
> After you've downloaded the gtk-osx and gnucash-on-osx, you need to modify gnucash-on-osx/.jhbuildrc-custom to reflect the Mac OS X SDK level that you want to use. As a word of warning, you can't build against the 10.10 (Yosemite) SDK on a 10.9 (Mavericks) machine, apparently since the build process needs to /run /some of the executables itself. If you're getting failures in gobject-introspection, this may be your problem.
> 
> Since recent versions of Mac OS X include the openssl libraries, I would rather not have another version lined into the application. That way I only have to update the OS version, not rebuild every time there is a security update. Unfortunately, I suspect that there are things like GNUTLS built in as well, which need their own patching. John Ralls said on IRC that one could also skip openssl with a command-line argument, but I prefer to have it be the "always" case.
> 
> I also modified it to re-point to my local build manifest, rather than pulling the one from jralls' github.
> 
> ===
> 
> diff --git a/.jhbuildrc-custom b/.jhbuildrc-custom
> index 940dd1e..ec7353d 100644
> --- a/.jhbuildrc-custom
> +++ b/.jhbuildrc-custom
> @@ -21,9 +21,16 @@ modules = ["meta-gtk-osx-bootstrap", "meta-gtk-osx-core", "gnucash"]
> #"ppc". Don't try to do a universal build, it doesn't work. x86_64 is
> #untested. Users on systems later than 10.6 will need to replace both
> #instances of "10.5" below with their OS version:
> -setup_sdk("10.5", "10.5",["i386"])
> +setup_sdk("10.9", "10.9",["i386"])
> 
> -moduleset = "http://github.com/jralls/gnucash-on-osx/raw/master/modulesets/gnucash.modules" 
> +# 10.7 and later already have openssl
> +# https://mail.gnome.org/archives/gtk-osx-users-list/2015-January/msg00001.html
> +# Note that it is skip.append(), not skip.add()
> +skip.append('openssl')
> +
> +# moduleset = "http://github.com/jralls/gnucash-on-osx/raw/master/modulesets/gnucash.modules"
> +
> +moduleset = "/Users/gnucash-build/Documents/devel/gnucash-on-osx/modulesets/gnucash.modules"
> 
> ===
> 
> Note that "gnucash-build" the the user name in the full path to gnucash.modules -- this would need to be modified for your path, or just leave moduleset alone and take the current version from github.
> 
> I recommend symlinking ~/.jhbuilrd-custom to path/to/gnucash-on-osx/.jhbuildrc-custom so that you have only one version of it on your file, and it is in your local git repo when you change it.
> 
> I'm under the belief that this should be done *before* building the gtk tools, as it sets the SDK, architecture, and  bit-ed-ness (32, at this point). If/when one goes to build 64-bit versions, you'd likely need to rebuild the tools as 64-bit as well.
> 
> I then build the tools. While Python has been updated on Mac OS X, I haven't been able to build the libxml2 wrapper required in a virtualenv, so I just deal with another full copy of python dedicated for this purpose.
> 
> I then run my prebuild script -- everything here *should* go smoothly
> 
> ===
> #!/bin/sh -v
> 
> cd ~/Documents/devel/gtk-osx
> 
> /bin/sh gtk-osx-build-setup.sh
> 
> PATH=~/.local/bin:$PATH
> 
> jhbuild build python && jhbuild bootstrap
> 
> ===
> 
> With the tools built, you should be able to *start* building GnuCash. It *will* fail the first time through...
> 
> ===
> #!/bin/sh -v
> 
> cd ~/Documents/devel/gnucash-on-osx
> 
> PATH=~/.local/bin:$PATH
> 
> jhbuild build
> 
> ===
> 
> In libsoup, it will crap out with something along the lines of
> 
> ... gobject-introspection/giscanner/sourcescanner.py", line 302, in _parse
>         proc.stdin.write('#ifndef %s\n' % (define, ))
> 
> This one is a good puzzle, and thanks to Philip Chimento, found at
> <http://comments.gmane.org/gmane.comp.gnome.gtk2.osx.devel/153>
> 
> > Here’s the weird part, and the work-around. They’re the same:
> 
> > Select 4 to open a shell. cd to glib-networking. Run
> >   make uninstall && make install
> > Quit the shell and select 1, rerun build. All will be well.
> 
> > How’s that for weird?
> 
> Yep -- do that and scratch your head as to why. Gotta love gobject-introspection.
> 
> It *should* complete the build.
> 
> I have run into another problem with interrupted or second builds:
> 
> ** Checking out bdw-gc *** [63/65]
> git remote set-url origin git://github.com/ivmai/bdwgc
> git remote update origin
> Fetching origin
> *** Error during phase checkout of bdw-gc: Refusing to switch a dirty tree. *** [63/65]
> 
> Here the resolution is to open a shell and
> 
> git reset --hard HEAD
> 
> then continue.
> 
> *** success *** [65/65]
> 
> =====
> 
> Once I get a reliable build process, I'm going to throw ccache in. I don't think it will help the build of guile though -- expect that to take a while and chew up all the cores your machine has in the process.
> 
> =====
> 
> OK, so now that it's built, I am unable to successfully run it. There is no gnucash-launcher in either ~/gtk/bin or ~/gnucash-stable/bin as called out on <http://wiki.gnucash.org/wiki/MacOSX/Quartz>. In fact, there isn't one anywhere that
> find ~ -name gnucash-launcher
> can find.
> 
> So, trying ~/gnucash-stable/bin/gnucash results in the UI starting to render, then nearly immediately dying with
> 
> ~/gnucash-stable$ ./bin/gnucash
> main: Error on gnc_gbr_init: Unable to open /proc/self/maps for reading.
> 2015-03-15 15:31:51.392 gnucash[74284:507] *** WARNING: Method userSpaceScaleFactor in class NSView is deprecated on 10.7 and later. It should not be used in new applications. Use convertRectToBacking: instead.
> Backtrace:
> In unknown file:
>   ?: 19 [apply-smob/1 #<catch-closure a121650>]
>   ?: 18 [call-with-input-string "(use-modules (gnucash engine))" ...]
> In ice-9/boot-9.scm:
> 2401: 17 [save-module-excursion #<procedure a5f8090 at ice-9/eval-string.scm:65:9 ()>]
> In ice-9/eval-string.scm:
>  44: 16 [read-and-eval #<input: string a0fe7e0> #:lang ...]
>  37: 15 [lp (use-modules (gnucash engine))]
> In ice-9/eval.scm:
> 505: 14 [#<procedure a0150e0 at ice-9/eval.scm:499:4 (exp)> (use-modules #)]
> In ice-9/psyntax.scm:
> 1106: 13 [expand-top-sequence ((use-modules (gnucash engine))) () ...]
> 989: 12 [scan ((use-modules (gnucash engine))) () ...]
> 279: 11 [scan ((# #) #(syntax-object *unspecified* # #)) () (()) ...]
> In ice-9/boot-9.scm:
> 3597: 10 [process-use-modules (((gnucash engine)))]
> 702: 9 [map #<procedure a0f10b0 at ice-9/boot-9.scm:3597:25 (mif-args)> ((#))]
> 3598: 8 [#<procedure a0f10b0 at ice-9/boot-9.scm:3597:25 (mif-args)> (#)]
> 2864: 7 [resolve-interface (gnucash engine) #:select ...]
> 2789: 6 [#<procedure a0eece0 at ice-9/boot-9.scm:2777:4 (name #:optional autoload version #:key ensure)> # ...]
> 3065: 5 [try-module-autoload (gnucash engine) #f]
> 2401: 4 [save-module-excursion #<procedure a206b58 at ice-9/boot-9.scm:3066:17 ()>]
> 3085: 3 [#<procedure a206b58 at ice-9/boot-9.scm:3066:17 ()>]
> In unknown file:
>   ?: 2 [primitive-load-path "gnucash/engine" ...]
> In engine.scm:
>   7: 1 [#<procedure a167030 ()>]
> In unknown file:
>   ?: 0 [load-extension "libgncmod-engine" "scm_init_sw_engine_module"]
> 
> ERROR: In procedure load-extension:
> ERROR: In procedure dynamic-link: file: "libgncmod-engine", message: "file not found"
> 
> Again, no libgncmod-engine in ~/gnucash-stable nor is there any 'engine' directory to be find-ed under ~ other than the source directory, gtk/source/gnucash-2.6.5/src/engine
> 
> 
> So, Question 1:
> 
> ===> What am I missing here in the build process?
> 
> 
> 
> Past that, it looks like the bundler is inconsistent with the actual output.
> 
>  <data dest="${bundle}/Contents/Resources/lib/">
>    ${prefix}/lib/libgnc-qof.la
>  </data>
> 
>  <data dest="${bundle}/Contents/Resources/lib/">
>    ${prefix}/lib/libgnc-*.la
>  </data>
> 
> Currently, .dylib libraries are being built, not .la libraries. When I get to the point of having a running GnuCash...
> 
> 
> Question 2:
> 
> ===> Should these references be changed to .dylib, or is there something else that needs to be done to get .la libraries?
> 

Jeff,

Thanks for the write-up of your experience.

The problem with libgncmod-engine can be fixed by ensuring that $JHBUILD_PREFIX/lib and $JHBUILD_PREFIX/lib/gnucash are included in $DYLD_LIBRARY_PATH. That's been fixed already in maint so the 2.6.6 tarball shouldn't have that problem.

Actually there are .dylib, .so, and .la libraries built, including libgncmod-engine.dylib and libgncmod-engine.la. There are places in GnuCash and in dependencies that use ltopen instead of dlopen, and the former looks for .la redirection files. The bundler instructions to copy those into the bundle is to ensure that those ltload calls work. jhbuild is a bit perverse about installing .la files, so you may need to run "make install" from your build directories in a jhbuild shell to get the .la files in place. In the past I've found this to be sometimes necessary for Guile as well as GnuCash.

.jhbuild-custom is intended to be revised to suit the user's needs; the one in gnucash-on-osx is only an example and since I don't use it, it's a bit subject to bit-rot. If you want to use your gnucash-on-osx repo for your revisions, set up a vendor branch so that you can easily pull updates.

gnucash-launcher is indeed obsolete, thanks to Geert having removed our dbus dependency with the new preferences system. I've updated the wiki to reflect that.

Regards,
John Ralls