Difference between revisions of "Windows"

Revision as of 13:13, 3 September 2006

GnuCash on Microsoft Windows

This page collects various notes about potentially compiling GnuCash on Microsoft Windows.

FAQ: Is it possible to compile GnuCash on Windows? A: Well, compiling is possible, but it doesn't run so far.

With the 2.x series now being released, gnucash is fully based on gtk2. This means it will probably be rather easy to finish a full windows port. "The other big application" Gnumeric already showed how to do it. Their UI code relies solely on gtk-2.x, i.e. they replaced every dependency on libgnomeui by its gtk equivalent. And gtk-2.x is fully available on windows. Obviously they managed to do this somehow, so I suspect it shouldn't be too difficult to do the same with gnucash. Also, one of our smaller competitors, Grisbi http://sourceforge.net/projects/grisbi , is offering a windows port by this very same strategy.

Some old gnucash-devel discussion:

• https://lists.gnucash.org/pipermail/gnucash-devel/2006-March/016916.html

Status: It is possible to compile, but it doesn't run so far. --Cstim 07:55, 3 March 2006 (EST)

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 [1]
• 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

See http://savannah.nongnu.org/bugs/index.php?func=detailitem&item_id=15972 and the LDFLAGS=-no-undefined has to be added also to guile/g-wrap/gw/Makefile.

Note: You need to have glib (2.x) installed first before you compile g-wrap so that g-wrap will generate and install wrappers for glib2 as well. The resulting wrapper shared libraries are named *gw-glib*.

Status: Compile is possible.

After installation, you should change the file guile/site/g-wrap/guile.scm (g-wrap 1.9.6; in older g-wrap this is in the file site/g-wrap.scm) and add the trailing "-0" to the place where a DLL should be loaded. Search for the string "dynamic-link" in that file and change the existing line

" (dynamic-link \"lib" wrapset-name "\"))))\n"))))))

into

" (dynamic-link \"lib" wrapset-name "-0\"))))\n"))))))

Frequent error: If you get the following linker error:

C:/msys/1.0/mingw/bin/../lib/gcc/mingw32/3.4.4/libgcc.a(w32-shared-ptr.o):: 
undefined reference to `_imp__GetAtomNameA@12'
undefined reference to `_imp__FindAtomA@4'
undefined reference to `_imp__AddAtomA@4'
undefined reference to `_imp__FindAtomA@4'

then it means that your windows DLL directory showed up first before your mingw DLL directory, i. e. the gcc linker command has -Lc:\WINNT\system32 before -L/mingw/lib. This wrong order might be caused from other, linked-in libraries, like from the libguile.la file in guile's library installation. To fix this: Edit the libguile.la file, remove -Lc:\WINNT\system32 so that you can correctly enfore that /mingw/lib comes first in the library search path.

Later, if you encounter the error ERROR: file: "libgw-guile-standard", message: "can't open the module" then you need to do one of the following:

• After some more thinking, we propose you should change the scheme command that looks for this DLL to look to the DLL with the trailing -0 instead. So you need to change the file $prefix/share/guile/site/g-wrap/guile/standard.scm line 8 to read

   (dynamic-link "libgw-guile-standard-0"))

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.

Prerequisites when using Cygwin

Cygwin

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.

g-wrap

See section above. Actually for cygwin no modifications are necessary in the source, in contrast to the mingw32 explanations above.

Gnucash

Initial notes about how to tweak ./configure so that it doesn't complain about the missing gnome packages were here [2] 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 --disable-error-on-warning --with-zlib=/c/GTK2-8-18 \
  LDFLAGS="-no-undefined -mms-bitfields -L/lib -L/mingw/lib -L/C/WINNT/system32 -lwsock32 -lregex" \
  CFLAGS="-I/usr/include -I/usr/local/include -D_WIN32 -DLIBLTDL_DLL_IMPORT -mms-bitfields" \
  PKG_CONFIG=/c/GTK2-8-18/bin/pkg-config \
  LD_LIBRARY_PATH=/c/GTK2-8-18/lib PATH="/c/GTK2-8-18/bin:$PATH"

If ./configure fails with error messages about "Cannot find the (g-wrap) guile module" or "Cannot find SLIB", you should check manually whether the error is really wrong. Do this by running guile -c "(use-modules (g-wrap))" or 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.

Now you need to do some changes in the file config.status. Change the line defining G_WRAP_MODULE_DIR, replace all forward slashes by properly quoted backslashes, e. g.

s,@G_WRAP_MODULE_DIR@,c:\\\\GTK2-8-18\\\\share\\\\guile\\\\site,;t t

so that guile at runtime will use the windows-style backslash path to find the g-wrap module directory. Otherwise the commands for building the g-wrap wrapsets will fail with "no such module" errors.

Then run ./config.status again.

(Note that the g-wrap wrapper generator didn't start up successfully when the current working directory was on the SMB share. The g-wrap wrapper generator only works when I'm on the local disc of the computer.)

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

Symlinks

During the build, various header files are expected to be located in subdirectories, which is simulated during normal Unix building by setting symlinks to the current working directory. On windows, a basic mingw32 environment doesn't have symlinks, so this needs more work.

As far as I currently now, you have to do some manual copying! The current gnucash build system has no way around it, because it assumes you can symlink to the current working directory. As mingw will silently replace "ln -s" by "cp -R", this will fail badly because it recursively tries to copy the current working directory into itself. Eventually it fails with "path name too long". That's why "ln -s" needs to be replaced by "touch", so that no recursive copying of directories is done.

First this will concern some header files for goffice and gsf. You will notice at some point that the build fails with "goffice-config.h: file not found". In that case in the top-level directory, make this: "rm goffice; mkdir goffice; cp goffice-features.h goffice-config.h goffice". Same thing for gsf.

In some cases, some .scm scheme files are expected in a subdirectory gnucash/ or g-wrapped/, and again by default gnucash on mingw would try to recursively copy the current working directory into itself. Instead, if you have replaced LN_S by "touch", you can wait until the build fails with some message about a scheme module not found, "(gnucash engine): module not found" or similar. Then, in the src/engine directory, do this: "rm gnucash; mkdir gnucash; cp engine.scm gnucash". Similar for modules like "(g-wrapped gw-engine)", except these are expected in the subdirectory g-wrapped.

Some older discussion on this topic:

Someone has used a free utility from the excellent people at SysInternals to create windows "Junctions". It's command line based, so it should be easy to use from a make file. Source is available too. More information is at their site: [3]

Since Windows 2000, XP, 2003, etc support symbolic links, why not just modify the make file so that on those platforms junctions are used? Thus any copy of Windows that does not support junctions would continue to be without a port of GnuCash but the vast majority would work. Any reason this has not been attempted?

I have not tested it, but you might try to download the "Windows Server 2003 Resource Kit Tools", they contain linkd.exe which should be able to create these junctions.

(Cygwin does support symlinks already in its default configuration. So that's not an issue there.)

goffice

The internal goffice subdirectory of gnucash doesn't immediately compile. A few changes are necessary:

• The headers <urlmon.h> and <htmlhelp.h> as well as the libraries urlmon and htmlhelp are unknown, at least on my windows system. Therefore the header goffice/utils/win32-stub.h needs to be edited to get rid of these headers, and goffice/utils/win32-stub.c as well. I simply removed the includes, and replaced the function calls in the c file by "return 0;".
• The HtmlHelp seems to be unavailable but is expected in goffice/gtk/goffice-gtk.c; I replaced in line 746 the "#elif defined(G_OS_WIN32)" by "#elif 0".

All changes are included in the diff available at https://lists.gnucash.org/pipermail/gnucash-devel/2006-March/016883.html

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.

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 C files in the standard configuration, which were 586 C files in r13657. 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.

The majority of checks can be run successfully as well (in src/gnc-module, 1 out of 20 fails; in src/engine, only 3 out of 22 fail). However there are problems with the installation of the gnucash scheme modules, which might probably need some tweaking with the guile path variables (backward vs. forward slashes and the like).

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]
• [9]
• [10]
• [11] (but will crash when clicking "ok" here)

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

Old notes

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

Latest (very new) notes

In SVN we now have a script to build the build environment: http://svn.gnucash.org/trac/browser/gnucash/trunk/packaging/win32

For guile-1.6.8, a binary package including slib plus the devel package is provided here: http://www.tu-harburg.de/~et2cs/gnc/ --Cstim 17:11, 25 August 2006 (EDT)