Difference between revisions of "Windows/Old Notes"

Revision as of 16:39, 3 January 2007

This is a collection of notes that describe how to build GnuCash on Windows and was a great source of information that was needed before automated tools, like install.sh, took control. Some parts are missing, some are to be considered obsolete, but a lot is still in use behind the scenes. See also [1] for docs how to build Evolution for further information about the GNOME stack.

Prerequisites when using MinGW32

Mingw32

See http://www.mingw.org . All available as pre-compiled binaries.

Many other pre-compiled binaries are also available from http://gnuwin32.sf.net/ . (All gtk-related packages like pkgconfig and libxml2, however, are already included in the large glade package, see below.)

SVN

There are multiple SVN clients for windows. The command-line program is in the http://subversion.tigris.org package. A GUI client that installs as a plugin to the Windows Explorer is on http://tortoisesvn.tigris.org but it is rather slow and clumsy.

guile

In guile-1.6.7 several tweaks were necessary to get it to compile. (We strongly discourage using guile-1.6.0 that is shipped with mingw - you should probably better remove it manually to make sure this very old version doesn't interfere with a more up to date version.)

• File libguile/fports.c line 479: replace "#elif defined(FIONREAD)" by "#elif 0"
• File libguile-ltdl/raw-ltdl.c lines 220, 222, 224: remove the LT_GLOBAL_DATA macro on each line. You might need to touch libguile-ltdl/upstream/ltdl.c.diff afterwards
• Files srfi/Makefile, libguile-ltdl/Makefile, libguile/Makefile: Add "-no-undefined" argument to libxyz_LDFLAGS variables, see also [2]
• Remove every occurence of fileblocks.* in config.status and run config.status.
• Remove the line containing SIGBUS in ice-9/boot-9.scm
• Set the env variable GUILE_LOAD_PATH to the actual load path, which is different from the one that was stored during compile due to mingw's path translation. Make e.g. export GUILE_LOAD_PATH='\msys\1.0\local\share\guile\1.6'
• For some srfi's, shared libraries are installed in $prefix/bin, e. g. libguile-srfi-srfi-13-14-v-1-1.dll. You need to copy these DLLs at the same location to a filename that does not have the last trailing "-1", which in this case is libguile-srfi-srfi-13-14-v-1.dll. On Linux, this would have been done by symlinks. On windows, it depends on the tools in use whether you can create symlinks (see below for more about symlinks). If you cannot use symlinks, you have to copy this manually.

One possible set of configure arguments looked like this:

./configure --disable-elisp --disable-networking --disable-dependency-tracking --disable-libtool-lock --disable-linuxthreads -C --prefix=/usr/local LDFLAGS="-L/lib -L/mingw/lib -L/C/WINNT/system32 -lwsock32 -lregex"

For testing, try to make sure "guile -v" will run and give you the version number. Then try a simple expression, like "guile -c '(display %load-path)'". With the change in ice-9/boot-9.scm, the guile command line interface should also work.

With the above DLL copying of srfi-13-14, code generation in g-wrap will actually work. It will will always show the error message "command 'indent' not found", though, but this can simply be ignored.

g-wrap

g-wrap has now been replaced by SWIG. There are binaries here.

glade

http://gladewin32.sourceforge.net This project offers a large (10MB) Installer which also includes all the rest of the gtk/glib platform, including pkgconfig, libxml2 and various other tools.

Note: After installation, the pkgconfig files have to be adapted to your installation path. See below in the gnome section for instructions.

glib

http://www.gtk.org/download/ has binary windows packages, but the binary is already included in the glade installer above, so no separate download is necessary.

gnome

A lot of windows binaries for gnome packages missing in the glade package can be found at ftp://ftp.gnome.org.

GConf, Orbit2, gail, gnome-{common, mime-data, vfs}, intltool, libIDL, libart_lgpl, libbonobo{,ui}, libgnome{,canvas,ui} and pango can be found at:

• Pick the latest available version under ftp://ftp.gnome.org/pub/gnome/platform which has a win32 subdirectory (the uneven numbers don't have that).

Libgnomeprint, libgnomeprintui and libgtkhtml can be found at:

• Pick the latest available version under ftp://ftp.gnome.org/pub/gnome/desktop which has a win32 subdirectory, preferrably the same version as the gnome/platform.

Or alternatively use this link ftp://ftp.gnome.org/pub/gnome/binaries/win32/ directly.

libgsf can be found here: http://www.gimp.org/~tml/gimp/win32/downloads.html (however it is unclear whether a combination of these different binary sources is very useful).

libglade-2.6.0 needs to be installed as well because the libglade of the glade installer (above) doesn't accept to load the "gnome" widgets which are installed by libgnomeui into $prefix/lib/libglade/2.0. Get libglade from here ftp://ftp.gnome.org/pub/gnome/binaries/win32/

GConf

After installation of gconf, check whether you can run the "gconftool-2.exe" program. If it doesn't show its usage message but instead fails with an error like "cannot find symbol freeaddrinfo in WS2_32.DLL", then your DLL of ORBit cannot be used on your system. In my case this error went away after upgrading ORBit to 2.13.3.

Paths in pkgconfig files

Previously we've proposed to hand-edit all pkgconfig files in your $prefix/lib/pkgconfig directory to fix their prefix= line, because it contains the path at build time instead of your installed path at installation time. However, it turns out pkg-config already overrides this prefix-variable automatically, see the section Windows Specialities in its man page. So you don't need to do perl -pi.bak -e's!^prefix=.*$!prefix=C:/GTK2-8-18!' *.pc anymore.

Previously in some gnome versions, two additional files had paths from build-time, namely pangocairo.pc and pangoft2.pc, where the line with Cflags: has an include directive pointing to a build-time directory. Replace the /home/ivan/cross/build/include by ${includedir} and everything should be fine. Currently these errors seem to have been fixed.

Finally, in pangoft2.pc the CFlags line is missing one -I${includedir}/freetype2; simply add this here, or otherwise you will run into "include file not found" errors when building goffice and/or any of gnucash's gnome directories.

goffice

Gnucash comes with a copy of goffice-0.0.4 which is used if no newer version of goffice is found during configure.

It might be worth a try to compile goffice from source in a newer version, available here: ftp://ftp.gnome.org/pub/gnome/sources/goffice/0.3 If you try to compile this, make sure you installed libgsf beforehand (see above). The source code of goffice-0.3.0 compiles (almost) unchanged on mingw32 except for one patch, see http://mail.gnome.org/archives/gnumeric-list/2006-August/msg00030.html but we expect this to be fixed quite soon in the official goffice distribution.

Avoiding the separate compilation of goffice in gnucash will save quite a lot of time at each recompilation of gnucash.

Gnucash

Initial notes about how to tweak ./configure so that it doesn't complain about the missing gnome packages were here [3] and older, but now the current information is written down below.

Build Instructions / hints

This is for a system where all the GTK and GNOME libs are installed in c:\GTK-2-8-18\.

./configure when using mingw32

In order to get ./configure to run successfully, the following one change was necessary compared to SVN configure.in. Apply that by hand, then run ./autogen.sh.

--- configure.in        (Revision 14371)
+++ configure.in        (Arbeitskopie)
@@ -39,7 +39,7 @@
 # order, doesn't it? Whatever.)
 AC_PROG_CC
 AC_GNU_SOURCE
-AC_PROG_INTLTOOL
+AC_PROG_INTLTOOL([],[no-xml])
 AM_GCONF_SOURCE_2

(You can skip this patch if you install ActivePerl and export INTLTOOL_PERL=${PathToPerlBin}. This package includes XML::Parser.)

Then run ./configure. The ./configure line used was

./configure --with-zlib=/c/GTK2-8-18 \
  LDFLAGS="-L/lib -L/mingw/lib -L/C/WINNT/system32 -lwsock32 -lregex" \
  CFLAGS="-I/usr/include -I/usr/local/include -D_WIN32" \
  PKG_CONFIG=/c/GTK2-8-18/bin/pkg-config

If ./configure fails with error messages about "Cannot find SLIB", you should check manually whether the error is really wrong. Do this by running guile -c "(use-modules (ice-9 slib)) (require 'printf)". In my case this worked fine, so somehow the environment during ./configure was messed up. I then disabled the check by editing the file ./configure directly, searching for lines containing use-modules and prepending that line by the echo command. This effectively ignores this test altogether.

If ./configure fails with error messages about unfulfilled dependencies of some gtk-related package, then the direct gnucash dependencies (e.g. "cairo") are probably fulfilled, but the indirect dependencies of the required package are probably not fulfilled. You can check this by opening the file cairo.pc and look for the lines Requires. If you simply want to ignore this test, you have to remove the unfulfilled package name from that line.

goffice

It is strongly suggested to use the externally compiled goffice.

Checks

If everything is compiled, you should try to get the tests running, i.e. "make check" to pass.

Test environment

When running "make check", a lot of environment variables are set before the actual test programs are called. These env variables should set the appropriate search paths to the locations in the build directory. However, these paths are in unix-notation with '/' as a directory separator, whereas for the windows programs they need to be in windows-notation with '\' as directory separator. Fortunately, the directory paths are passed through a script inside the gnucash source tree, which offers the necessary path name conversions. Simply edit the file src/gnc-test-env and change line 17 so that it reads

(define is-windows? #t)

If you didn't change the paths properly into Windows conventions, you will keep getting error messages in src/gnc-module/test/ as follows:

** (test-load-c.exe:752): WARNING **: Failed to open module gnucash/foo
** (test-load-c.exe:752): WARNING **: : could not locate gnucash/foo interface v.0

First g-wrap DLLs

When the environment is properly set in the Makefiles, you should run "make check" in src/gnc-module/check.

At the first test (test-load-c) I encountered an error dialog box (!) saying "c:\gtk2-8-18\lib\libgw-guile-standard.a is not a valid DLL"; however, after clicking Ok the test nevertheless succeeds(!). So this error can be ignored, but if it bothers you, you should move this libgw-guile-standard.a to a different filename in order to disable it. This workaround applies for all further error messages about "libxy.a", and in each case I'd propose to move it to a different filename, e.g. "libxy.a-disabled".

Code for scheme modules

At the next test (test-load-scm), I encountered the error message

ERROR: no code for module (gnucash gnc-module)

This one means that guile looks for a file gnc-module.scm but in a subdirectory gnucash/. This subdirectory is normally accessible by the symlink gnucash in src/gnc-module; however, I had disabled this symlink creation because my mingw32 version doesn't have Windows symlinks/junctions. As a workaround for this particular file, I created the subdirectory gnucash manually and copied the file gnc-module.scm into that subdirectory.

Same for the next error:

ERROR: no code for module (g-wrapped gw-gnc-module)

Guessed it? I needed to create the subdirectory g-wrapped and copy the file gw-gnc-module.scm to that directory.

And that's it! After these changes I was able to run "make check" in gnc-module.

xmlparse.dll

When running make check in the src/engine directory, I got the error message

Procedure entry point XML_SetDoctypeDeclHandler not found in xmlparse.dll

This is solved by locating a second copy of xmlparse.dll that exists in the c:\WINNT\system32 directory, which conflicts with gtk's original one in C:\GTK2-1-18\bin. Renaming xmlparse.dll and xmltok.dll into something else solved this. Proposed from here [4].

Installation

Yes, it is possible to run "make install" eventually. I've done it. Really.

One issue showed up on startup: When initially dlopen'ing all the gnucash modules, this takes a long time because libtool has the great idea to look up all dependencies when loading these libraries. As a workaround, go into $prefix/lib/gnucash after installation and execute this:

for A in *.la; do grep -v dependency_libs $A > tmp ; mv  tmp $A; done

gconftool

One issue that occurs on "make install" is that gconftool-2.exe refuses to execute the normal steps that are done when installing the apps_gnucash_xy.schemas files. Instead it shows the error message

mkdir -p c:/entwicklung/gnucash/etc/gconf/gconf.xml.defaults
GCONF_CONFIG_SOURCE=xml::c:/entwicklung/gnucash/etc/gconf/gconf.xml.defaults \
  /c/entwicklung/gnome/bin/gconftool-2 --makefile-install-rule ./apps_gnucash_history.schemas
DefaultConfigFile: 
Failed to load source "xml": Couldn't resolve address for configuration source: Bad address `xml'
Failed to load source "c": Couldn't resolve address for configuration source: Bad address `c'
Failed to load source "C:\msys\1.0\entwicklung\gnucash\etc\gconf\gconf.xml.defaults": \
  Couldn't resolve address for configuration source: Bad address \
  `C:\msys\1.0\entwicklung\gnucash\etc\gconf\gconf.xml.defaults': `\' is an \
  invalid character in a configuration storage address

and then a dialog box (!) with a failed assertion in gconftool-2.exe pops up and the whole installation run is terminated.

One workaround was to define the GCONFTOOL variable as a no-operation during "make install", e.g.

make GCONFTOOL=echo install

Another workaround is to disable the installation of the schemas by the corresponding gconf configure option, i.e. when configuring gnucash, use

./configure --enable-schemas-install=no ...

Status

The windows port successfully compiled. All gnucash modules can be linked successfully. All test executables can be compiled and linked as well. It is possible to run "make install" successfully until end.

Screenshots

The good news is: Even starting the gnucash executable is possible. At first it failed quite soon because it cannot load some of the loadable modules. Here's what I saw:

• [5] (which can be ignored)
• and [6] (which is solved by copying $prefix/share/gnucash to /C/GTK2-8-18/share/gnucash) and
• [7] (which is unsolved so far).

After some more combined effort of Andi, Derek, and myself, we saw these:

• [8] (the warning is solved by installing the latest libglade in the same prefix as libgnomeui)
• [9] Opening a file
• [10] (solved in current SVN)
• [11] Adding a new account (but will crash when clicking "ok" here)

And after loading a file has been fixed in SVN, we see these:

• [12] Account tree
• [13] Register window
• [14] Editing a transaction and in particular the account field in the register window

Note: Due to the file system wrapper layers in mingw32, compiling and especially linking is extremely slow. A full build of the gnucash tree might take well over 6 hours on a normal PC.

Also see http://svn.gnucash.org/trac/browser/gnucash/trunk/packaging/win32

Other Solved Problems

gdb: Entry Point Not Found

When I attempt to run GNUCash with gdb (following instructions above) I get a Windows dialog box titled "gnucash-bin.exe - Entry Point Not Found" with the following message:

The procedure entry point g_slice_alloc could not be located in the 
dynamic link library libglib-2.0.0.dll.

Any ideas? --Scbash 17:22, 3 December 2006 (EST)

Have you installed several glib's to different prefixes? Does setting the environment variable G_SLICE=always-malloc change something? -- andi5

Looks like I edited gnucash.bat rather than the gnucash script. Calling gdb from the right place makes everything work fine.--Scbash 16:00, 9 December 2006 (EST)

Errors in building autoconf: autom4te: need GNU m4 1.4 or later: /bin/m4

Hi everyone. I spent some of the Thanksgiving weekend trying to build GNUCash in Windows. Everything proceeded fairly well until I got to the autotools section of the build, at which point I got a vague error about requiring m4 version 1.4 or later. Here is the last little bit of the make output before the crash:

make[2]: Leaving directory `/c/soft/tmp/autoconf-2.60/lib/m4sugar'
autom4te_perllibdir='..'/lib AUTOM4TE_CFG='../lib/autom4te.cfg'
../bin/autom4te -B '..'/lib -B '..'/lib --language M4sh --cache 
--melt ./autoconf.as -o autoconf.in
The system cannot find the path specified.
autom4te: need GNU m4 1.4 or later: /bin/m4
make[1]: *** [autoconf.in] Error 1
make[1]: Leaving directory `/c/soft/tmp/autoconf-2.60/bin'
make: *** [all-recursive] Error 1

On a second try, after only installing msys 1.0.10 and nothing else, and running install.sh, the inst_dtk section outputs:

############################################################
###  MSYS DTK
############################################################
msys dtk already installed.  skipping.

which confuses me. I didn't install the DTK.

New thought: looking at the inst_dtk function, it checks if "perl --help" returns. I had ActivePerl pre-installed, so that may be the problem, because that test thinks the MSYS DTK is already installed whereas in reality only ActivePerl had been installed.

Okay, forcing the DTK install got it past the m4 error listed above. Looks like my original install of ActivePerl was the problem. I commented out the check for "perl --help" in install.sh, restarted install.sh, and the build seems to be going along fine now. I'll let you know if I run into another issue. Thanks! --scbash 21:06, 27 November 2006 (EST)

This is fixed now in SVN by changing the test for the installed perl. --Cstim 04:28, 29 November 2006 (EST)

Misc notes and issues

• There was a weird linker problem in the early porting effort. The src/gnc-module/libgncmodule.la DLL doesn't export its symbols. This DLL simply won't have any exported symbols, in stark contrast to e.g. src/core-utils/libcore-utils.la, which has all symbols exported just fine. My checking for exported symbols was nm .libs/libgncmodule.dll.a | grep ' T '. Turns out the libtool header <ltdl.h> must have the macros _WIN32 and in particular LIBLTDL_DLL_IMPORT defined or otherwise the linking will fail on windows. Once I do this, these variables marked with "C" disappear in the object file, and all expected symbols correctly appear. That's why these macros are included in the above configure command now. Of course this is nowhere documented, thank you libtool.
• In goffice, one include directory was missing and needs to be added to CFLAGS, either in config.status or manually in the Makefiles: -I/c/GTK2-8-18/include/freetype2 ; either this is fixed in gnucash, or you fix the pkgconfig file pangoft2.pc as described in the gnome section above.
• I got DLL problems when running tests and/or starting gnucash-bin.exe. The error message is something like "cannot find symbol freeaddrinfo in WS2_32.DLL". This was fixed by upgrading ORBit to 2.13.3.

Cygwin prerequisites

Install the latest cygwin setup.exe from http://cygwin.com/. Let it install its minimum package selection. Then, start the cygwin setup.exe again and select the following development packages to be installed (and of course its corresponding runtime packages, in case they don't get selected automatically):

GConf2-devel ORBit2-devel atk-devel autoconf automake gettext-devel glib2-devel gnome-vfs2-devel gtk2-x11-devel guile-devel intltool libbonobo2-devel libfontconfig-devel libfreetype2-devel libgdbm-devel libgnome2-devel libgnomecanvas2-devel libgnomeui2-devel libncurses-devel libxml2-devel pango-devel pkgconfig

However, cygwin stopped building somewhere in src/engine due to unresolved lt_dlopen() symbols, regardless of which CFLAGS I used above in ./configure. That, and the additional slowing down of the build, turned me away from cygwin so I didn't continue building there. If you want to run a complete build under cygwin, good luck, but so far I haven't completed it. --Cstim 04:39, 16 August 2006 (EDT)

gtkhtml-3.x

All necessary Gnome packages are available as standard cygwin packages through the cygwin installer. The only notable exception is gtkhtml-3.x (standard cygwin only has libgtkhtml-2.x). That package can be retrieved as explained here http://cygwinports.dotsrc.org/ by adding the following URL to the server list: ftp://sunsite.dk/projects/cygwinports Then a gtkhtml-3.x version is available to be downloaded.

./configure when using cygwin

The configure line when using cygwin is much simpler than above:

./configure --disable-error-on-warning LDFLAGS="-no-undefined -mms-bitfields" \
 CFLAGS="-D_WIN32 -DLIBLTDL_DLL_IMPORT"

However, cygwin stopped building somewhere in src/engine due to unresolved lt_dlopen() symbols, regardless of which CFLAGS I used above in ./configure. That, and the additional slowing down of the build, turned me away from cygwin so I didn't continue building there. If you want to run a complete build under cygwin, good luck, but so far I haven't completed it. --Cstim 04:38, 16 August 2006 (EDT)

pkg-config

Error: Endless loop with "The application failed to initialize properly (0xc0000142)." problem is in install.sh (rev.15222 lines 541,546) the pkg_config here-file should not use the $(PKG_CONFIG) variable since it creates a self-referential-script.

Indeed, r15215 (r12155 is irrelevant here) introduced a regression, because the pkg-config-msys.sh script must not use $PKG_CONFIG as we export that. (Cstim says: Sorry, I replaced too much of pkg-config calls - my fault.) Fixed in r15224.