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

[Jeff Kletsky]

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?



Thanks,

Jeff