Revision as of 18:41, 18 October 2013

This page will collect useful information to develop GnuCash on Windows. If you were looking for tips regarding using GnuCash on Windows, you should read the Windows page instead.

A bit of history

This page used to collect random notes from the time when we manually tried to install each and every part of the requirements. They have been moved to Windows/Old Notes.

Instructions for an (almost) automated build

These instructions explain how you can compile and run GnuCash on MS Windows by yourself. This is achieved by using the mingw32/gcc compiler environment. (If you want to use the Visual Studio compiler, see the sub-project Cutecash, but the instructions below must be followed first as well.)

We've created a shell script that will download, compile, and install all requirements of GnuCash on Windows and eventually GnuCash itself. Running this script will probably download ~200MB of data (but all downloaded data will be cached) and will take anything between 0.5 through 5 hours of time. That shell script is located in packaging/win32/install.sh of the gnucash SVN sources.

Warning: Windows XP or more recent is required for building Gnucash using install.sh (see below). Windows 2000 support was dropped starting from GnuCash 2.3.10, older versions of Windows are not supported.

Some notes upfront

GnuCash is currently in a transition from svn to git as the master repository. Currently either version control system can be used still, but git will be the preferred one in the future. These instructions will explain what is required for both systems. Git specific actions will be marked with git, subversion specific actions will be marked with svn.
In the following discussion, the c:\soft root folder should be replaced by whatever base folder you wish to work in. Avoid pathnames with spaces in them (so c:\Program Files is not good). Some parts of the build system don't cope well with that. If you choose a path other than c:\soft, be sure to set the GLOBAL_DIR parameter to this path in custom.sh later on (see below).
When installing packages in the script, it is strongly recommended that the expected locations are specified. Example: msys in c:\soft\msys.

Before you can execute this shell script (which will do everything else automatically), you have to complete these steps manually:

git Download and install git for Windows. The preferred location to install it is $GLOBAL_DIR\git-1.7.10. If you install in another location, you will have to set GIT_DIR in custom.sh later on. The installer will add some git related items in the Windows Explorer context menus (you can access them via right-click in any directory)

svn Download and unpack subversion for Windows on your system. The preferred location to unpack this file into is $GLOBAL_DIR\svn. If you install in another location, you will have to set SVN_DIR in custom.sh later on.

Choose a spot where you want to store a copy of the GnuCash repository. The default path is $GLOBAL_DIR\gnucash\repos.

Create all directories in the path except the last one. For the example, make sure $GLOBAL_DIR\gnucash exists

git Open a Windows explorer and go to $GLOBAL_DIR\gnucash (or your chosen location)

git Right-click. In the popup select git bash. This will open a command prompt.

git Enter: git clone git://github.com/Gnucash/gnucash.git repos The last part should be what you chose the call the directory to store the copy of the GnuCash repository.

svn Open a Windows command prompt (cmd) and enter the following command

 c:\soft\svn\bin\svn checkout http://svn.gnucash.org/repo/gnucash/trunk c:\soft\gnucash\repos

Replace c:\soft\gnucash\repos with whatever you chose as the location for your GnuCash repository, and c:\soft\svn with whatever path you chose to install svn in.

Go into the directory c:\soft\gnucash\packaging\win32.

Take a look at the comments at the top of defaults.sh and optionally create a file custom.sh to specify directories according to your preferences; the defaults would install everything in subdirectories below c:\soft. (Note that due to shell syntax, every windows-style backslash has to be specified as two backslashes.) Do not modify defaults.sh; make a custom.sh.

In here you may also specify GLOBAL_DIR, REPOS_DIR, SVN_DIR, GIT_DIR,... if you installed any of these in a non-standard directory.
If you chose to use svn as version control system, also add REPOS_TYPE="svn" in custom.sh.

Download the "MSYS" package from https://sourceforge.net/downloads/mingw -> MSYS -> Base -> msys-core -> msys-1.0.11 -> MSYS-1.0.11.exe Direct Download link

Execute this downloaded package to install it into the chosen directory, say, C:\soft\msys (which is the $MSYS_DIR variable in defaults.sh, and is strongly recommended; be sure to override $MSYS_DIR in custom.sh if you put it somewhere else.) NB: That's not C:\soft\msys\1.0, just C: \soft\msys!

Download the "wget" package from https://sourceforge.net/downloads/mingw -> MSYS -> Extension -> wget -> wget-1.12-1 -> wget-1.12-1-msys-1.0.13-bin.tar.lzma Direct download link and place the downloaded file in the $DOWNLOAD_DIR in defaults.sh

Start the MSYS commandline shell by double-clicking the "MSYS" icon on the desktop which should have been created when you installed the MSYS package.

Let the automated build begin by typing:

 $INSTALLER_DIR/install.sh   (the complete path to the install.sh)
 (e.g. /c/soft/packaging/win32/install.sh, or to save the log, 
 /c/soft/packaging/win32/install.sh 2>&1 | tee /c/soft/Build.txt)

If you get an error about the "tools" directory not existing, just make it (i.e. $GLOBAL_DIR\tools)

If you get an error about unzip not found, re-run install.sh. This is also usually the case about packages not found, after they have been installed.

Some of the downloaded packages are installed through graphical installer dialogs where you can choose an installation directory. In those cases, the install.sh script will tell you in the MSYS window the installation directory that you should choose, according to your settings in defaults.sh/custom.sh. Please enter only those installation directory in the installer dialog because otherwise the install.sh script cannot find the newly installed software.

If there haven't been any errors, you should be able (after several hours of compiling and installing) to start gnucash from the MSYS command line by typing

 c:/soft/gnucash/inst/bin/gnucash

or even without MSYS directly by "Start"-> "Run"-> "c:\soft\gnucash\inst\bin\gnucash.bat"

On Windows Vista Home Premium, open a windows command prompt, "cd \soft\gnucash\inst\bin" and then type "gnucash-launcher.cmd"

If you want to make a distribution executable, execute the following commands in MSYS, after executing install.sh described above.

 rm -rf /c/soft/gnucash/dist
 /c/soft/packaging/dist.sh

To start fresh with new package installs and cleaned out environment variables, after messing up the package installs, execute in MSYS, as for install.sh above, then restart your computer to eliminate environment variable problems such as with ACLOCAL:

 c:/soft/packaging/win32/reset.sh

To make modifications to your own source (svn will attempt to merge your changes with the source on the server during the install.sh build), that is in

 c:/soft/gnucash/repos/src

If there HAVE been errors, then please report them in the Section Problems, issues, comments.

When compiled from source, GnuCash will display in the default GTK Raleigh theme. The GnuCash binary installer defaults to the GTK-Wimp theme, which defers rendering of widgets to Windows for a native look-and-feel. Copy gtkrc from C:\soft\gnome\share\themes\MS-Windows\gtk-2.0 to C:\soft\gnome\etc\gtk-2.0 to change themes.

Please spread the word and report back any problems you encounter. It is probably not too difficult anymore to create a full self-contained package of GnuCash on Windows as well! Some more information is also collected here on this wiki page.

Working on Gnucash

Once you've successfully built Gnucash and all of its dependencies, it's a bit of a pain to re-run install.sh after every edit. To use make from the command prompt as usual, you need to set the following environment:

export OLDPATH=$PATH

PATH=/c/soft/svn/bin:$PATH
PATH=/c/soft/autotools/bin:$PATH
PATH=/c/soft/swig:$PATH
PATH=$PATH:/c/soft/active-perl/ActivePerl/perl/bin
PATH=$PATH:/c/soft/aqbanking/bin
PATH=$PATH:/c/soft/gwenhywfar/bin
PATH=$PATH:/c/soft/autotools/bin
PATH=$PATH:/c/soft/enchant/bin
PATH=$PATH:/c/soft/gmp/bin
PATH=$PATH:/c/soft/gnome/bin
PATH=$PATH:/c/soft/gnutls/bin
PATH=$PATH:/c/soft/goffice/bin
PATH=$PATH:/c/soft/guile/bin
PATH=$PATH:/c/soft/libdbi/bin
PATH=$PATH:/c/soft/libgsf/bin
PATH=$PATH:/c/soft/libofx/bin
PATH=$PATH:/c/soft/libsoup/bin
PATH=$PATH:/c/soft/libxslt/bin
PATH=$PATH:/c/soft/mysql/bin
PATH=$PATH:/c/soft/mysql/lib
PATH=$PATH:/c/soft/opensp/bin
PATH=$PATH:/c/soft/pcre/bin
PATH=$PATH:/c/soft/pgsql/bin
PATH=$PATH:/c/soft/pgsql/lib
PATH=$PATH:/c/soft/regex/bin
PATH=$PATH:/c/soft/sqlite3/bin
PATH=$PATH:/c/soft/webkit/bin

export PATH

export LTDL_LIBRARY_PATH=/c/soft/gnucash/inst/lib
export GNOME2_PATH=/c/soft/gnome
export INTLTOOL_PERL=/c/soft/active-perl/ActivePerl/perl/bin/perl
export GIT_CMD=/c/soft/git/git
export ACLOCAL_FLAGS="-I/c/soft/guile/share/aclocal -I/c/soft/gwenhywfar/share/aclocal -I/c/soft/aqbanking/share/aclocal -I/c/soft/autotools/share/aclocal -I/c/soft/gnome/share/aclocal -I/c/soft/gnutls/share/aclocal"

I put all of those commands into a file called devrc and then source it into my shell:

. devrc

$OLDPATH is there so that you can reset the path easily:

export PATH=$OLDPATH

The other piece of the puzzle is that you need to specify some environment to configure. Paste the following into a file (in your top-level source directory) -- I call mine .configure:

./configure \
	    --prefix=/c/soft/gnucash-inst \
	    --enable-aqbanking \
	    --enable-ofx \
	    --enable-debug \
	    --enable-schemas-install=no \
	    --enable-dbi \
	    --with-dbi-dbd-dir=/c/soft/libdbi-drivers/lib/dbd \
	    --enable-binreloc \
	    --enable-locale-specific-tax \
	    CPPFLAGS="$CPPFLAGS -I/c/soft/autotools/include -I/c/soft/regex/include -I/c/soft/gnome/include -I/c/soft/guile/include -I/c/soft/libdbi/include -I/c/soft/gmp/include -I/c/soft/gwenhywfar/include -I/c/soft/libsoup/include -D_WIN32 -ggdb3 -Wall -Werror -fno-builtin-dgettext -fno-builtin-towupper -fno-builtin-iswlower" \
	     LDFLAGS="$LDFLAGS -L/c/soft/autotools/lib -L/c/soft/regex/lib -L/c/soft/gnome/lib -L/c/soft/guile/lib -L/c/soft/libdbi/lib -L/c/soft/gmp/lib -L/c/soft/gwenhywfar/lib -L/c/soft/libsoup/lib -L/c/soft/enchant/lib -L/c/soft/libxslt/lib -L/c/soft/sqlite3/lib" \
	       PKG_CONFIG_PATH=/c/soft/autotools/lib/pkgconfig:/c/soft/regex/lib/pkgconfig:/c/soft/gnome/lib/pkgconfig:/c/soft/guile/lib/pkgconfig:/c/soft/libdbi/lib/pkgconfig:/c/soft/gmp/lib/pkgconfig:/c/soft/gwenhywfar/lib/pkgconfig:/c/soft/libsoup/lib/pkgconfig:/c/soft/aqbanking/lib/pkgconfig:/c/soft/libofx/lib/pkgconfig:/c/soft/isocodes/lib/pkgconfig:/c/soft/libonoboui/lib/pkgconfig:/c/soft/libgsf/lib/pkgconfig:/c/soft/libxslt/lib/pkgconfig:/c/soft/webkit/lib/pkgconfig:/c/soft/enchant/lib/pkgconfig:/c/soft/gnutls/lib/pkgconfig:/c/soft/goffice/lib/pkgconfig

Then you call .configure instead of configure before you run make

Alternative way to develop on a Windows machine

You may also prefer to work on GnuCash in its native environment. An alternative approach to developing GnuCash on Windows could be to

download a Linux Distribution of your choice and
use Multi Boot to switch between Windows and Linux or
run Linux in a Virtual Machine and
develop under Linux.

Notes

Error messages, Trace file

When running into problems when running GnuCash, the trace file is usually your first stop to look for errors. You will find more details on this file here (Windows specific) and here (More generic).

Debugging with gdb

In addition to Stack Trace, here are a few instructions on how to run gnucash under gdb on Windows:

Install "gdb" from mingw.org [1]
GnuCash 2.2.9 and older

Modify the installed "bin\gnucash.cmd" script by inserting one and changing one line. It should end like

    set PATH=C:\Program Files\gdb\bin;%PATH%
    start gdb --args gnucash-bin %*

Be careful to use the actual paths in which you have installed gdb.exe

Then start gnucash as usual

GnuCash 2.4.0 and more recent

Open a Windows command prompt and type:

    set PATH=C:\Program Files\gdb\bin;%PATH%
    gdb "C:\Program Files\gnucash\bin\gnucash"

Be careful to use the actual paths in which you have installed gdb and gnucash respectively.

For all versions: this will open a gdb prompt
Type run at the gdb prompt.
Then provoke the crash and type backtrace or shorthand bt at the gdb prompt to obtain the backtrace, as explained on Stack Trace as well.

(2.2.9 and older only)If you are working in a MinGW shell, you may want to change and call the bin\gnucash script instead and use exec start gdb --args gnucash-bin "$@" to make Ctrl-C actually work.

If you build gnucash with the help of install.sh, make sure you export DISABLE_OPTIMIZATIONS=yes in packaging/win32/custom.sh to include debugging symbols and avoid optimizations that complicate debugging.

You can provide even better stack traces if you tell gdb where in memory dynamically loaded modules got mapped to, because otherwise function calls into those are only written as '??'. See here and here for a way to do this.

To enter [ and ], use set editing off.

install.sh

To debug install.sh, change set -e to set -ex at the top of it.
Once you have installed Subversion, you might want to freqently checkout and update packaging/win32 as described in SVN.

svn checkout http://svn.gnucash.org/repo/gnucash/trunk/packaging/win32 packaging

Console output and exetype

All executables and DLLs on Windows operate in one of a few different subsystems, most of them either in Console or GUI (also called Windows). Basically, executables in Console always start up in a new console window and print output for stdout und stderr to it, whereas ones in GUI do not open windows and are pretty quiet, even in console windows. If you want to change that subsystem type, because you want to see debugging output or hide unnecessary console windows, [2] lists a few possible ways.

The easiest option if you don't have any further build tools available is probably the third one from that mail: Install the MSYS program (needed for building GnuCash) from the pointer at the top section of this page, fetch http://svn.gnucash.org/trac/browser/gnucash/trunk/packaging/win32/exetype.pl and type

exetype.pl gnucash-bin.exe console

If you are building gnucash with install.sh, you might want to automate this step. To do so, just add the following lines to the function make_install in your local install.sh (after "make install"):

   qpushd $_INSTALL_UDIR/bin
   	exetype gnucash-bin.exe console
   qpopd

Problems, issues, comments

DLL install error

I get an error like that:

'libgncmodule.la' 'c:/soft/gnucash/lib/libgncmodule.la'
/bin/install -c .libs/libgncmodule.dll.a
c:/soft/gnucash/lib/libgncmodule.dll.a
base_file=`basename ${file}`
  dlpath=`/bin/sh 2>&1 -c '. .libs/'${base_file}'i;echo $dlname'`
make[5]: *** [install-libLTLIBRARIES] Error 1
make[5]: Leaving directory `/c/soft/repos/src/gnc-module'
make[4]: *** [install-am] Error 2

This seems to be only an installation problem. Fine compiling it seems.

I saw this at "make install" when I stopped and restarted the preceding compiling several times. So to me this looks like an artifact of DLLs that somehow "don't fit" to each other. The solution was always to run "make clean" in the source directory so that all DLLs are being deleted, and then starting the compiling again. --Cstim 05:55, 4 December 2006 (EST)

I still see this error frequently, even when I completely remove the build/ directory and let it be created from scratch. (?!?) As an alternative, I've now tried a newer libtool version by installing the cvs snapshot libtool-1.5.23a from http://www.gnu.org/software/libtool/ . Maybe the newer version has this bug fixed. --Cstim 10:27, 22 January 2007 (EST)

Seems like using libtool-1.5.23a didn't change a thing. I've written a script that should track down potential errors:

#!/bin/sh
ALL_LIBDIR=` find . -name '*.la' | grep '\.libs' `
RM_THESE=""

for LIB in $ALL_LIBDIR ; do
    DIR=`dirname ${LIB}`
    FNAME=`basename ${LIB}`
    LIBBASE=`basename ${LIB} .la`
    if test ! -f "${LIB}i" -a -f "${DIR}/${LIBBASE}.dll.a" ; then
	echo "File ${LIB}i missing"
	PDIR=`dirname ${DIR}`
	#echo "Do this: rm ${PDIR}/${FNAME}"
	RM_THESE="${RM_THESE} ${PDIR}/${FNAME}"
    fi
done

if test "x${RM_THESE}" != "x"; then
    echo "Do this:"
    echo "rm ${RM_THESE}"
fi

So how is someone supposed to use the above script? It says it is supposed to track down potential errors, since it is doing some erasing (rm) does that mean it is fixing the problems as well? Or at least fixing it such that running install.sh again should work?

I have now run make clean && make all install in a particular directory 3 times but still get the same error.

Missing file after extracting Open SSL on Windows XP Pro

Note I have never run across this issue pop since I started to work with the Windows build (somewhere in the 2.3.x period). So it may no longer be relevant. There is however not date or version information in the message, so I'll keep it around for now. It may move to the History section at some point. --GJanssens 2013-10-18

This is the error that I got:

3200K .......... .......... .......... .......... .......... 99%  145.77 KB/s
3250K .......... ...                                        100%  834.05 KB/s


20:36:43 (145.65 KB/s) - `c:/soft/tmp/openssl-0.9.8e.tar.gz' saved [3341665/3341665]


Extracting openssl-0.9.8e.tar.gz ... done
The system cannot find the path specified.

This is the first error that I got. Everything was fine up to this point.

When I turn on set -ex, I get the following:

++ cp e_os.h e_os2.h include/openssl
+++ unix_path 'C:\WINDOWS\system32\cmd.exe'
+++ echo 'C:\WINDOWS\system32\cmd.exe'
+++ sed 's,^\([A-Za-z]\):,/\1,;s,\\,/,g'
++ _COMSPEC_U=/C/WINDOWS/system32/cmd.exe
++ PATH=/c/soft/active-perl/ActivePerl/Perl/bin:/c/soft/mingw/bin
++ /C/WINDOWS/system32/cmd.exe //c 'ms\mingw32'
The system cannot find the path specified.

Does that mean that your system lacks C:\Windows\System32\cmd.exe, $TMP_DIR\openssl-0.9.8e\ms\mingw32.bat or what do you think?

C:\Windows\System32\cmd.exe is definitely there.
So is C:\soft\tmp\openssl-0.9.8e\ms\mingw32.bat.

If I hardcode the full path to mingw32 in install.sh like this:

 PATH=$_ACTIVE_PERL_UDIR/ActivePerl/Perl/bin:$_MINGW_UDIR/bin $_COMSPEC_U //c c:\\soft\\tmp\\openssl-0.9.8e\\ms\\mingw32

ming32.bat starts to execute but it generates its own set of errors:

 > perl Configure mingw         
 Can't open perl script "Configure": No such file or directory
 Generating x86 for GNU assember
 Bignum
 The system cannot find the path specified.
 Can't open perl script "bn-586.pl": No such file or directory
 Can't open perl script "co-586.pl": No such file or directory
 DES . . .

So to get beyond that problem, I modified mingw32.bat to start out with a cd command, since it was starting in the C:\ directory:

 cd C:\soft\tmp\openssl-0.9.8e
 perl Configure mingw %1 %2 %3 %4 %5 %6 %7 %8
 @echo off

which allowed it to run a bit further and generated this error:

 Generating x86 for GNU assember
 Bignum
 DES
 crypt
 Blowfish
 CAST5
 RC4
 MD5
 SHA1
 RIPEMD160
 RC5\32
 CPUID
 Generating makefile
 Generating DLL definition files
 Building the libraries
 Building OpenSSL
 mingw32-make: *** [banner] Error 1

I don't think I should keep making these minor adjustments to install.sh and mingw32.bat. There must be something I've done wrong that is causing this problem to appear in the first place.

--FELap09

I am sorry, I do not really know how to help you other than "delete c:\soft\tmp\openssl-*, c:\soft\openssl and retry with -ex". -- andi5

I had a similar problem compiling OpenSSL. It was fixed by uninstalling mingw from its custom location, then allowing the install.sh script to reinstall it. -- cedayiv

Logitech QuickCam conflicts

Some Logitech QuickCam software is incompatible with MSYS, and causes the install.sh script to randomly crash and create sh.exe.stackdump files. If you experience this problem, see the MSYS FAQ page or the MinGW mailing list for help.

Older information, mainly for reference

Guile 1.8

The following is obsolete: The build scripts for 2.4 and trunk correctly build Guile 1.8. The notes are retained for historical interest.

GnuCash/Windows currently uses guile 1.6.x. Guile's development continues and the use of this old, no longer supported version of guile is blocking some improvements. Recent examples of this were:

Guile 1.8.7 removed some deprecated functions. However, the replacement functions were not available in 1.6.x. Because of this, GnuCash has to carry a compatibility header. We were lucky to get away with that.
Andy Wingo provided patches to make GnuCash work with the upcoming guile 2.0 and to remove our dependency on slib. These patches are incompatible with guile 1.6.x (and likely will always be), so they couldn't all be applied.

I have been attempting for some time to build a more recent version of guile but this turns out to be rather difficult. At the time of this writing, I have a working guile, save it won't load slib. There were many small things I had to do to get to this point. In order not to forget them, I've chosen to document them here.

Getting it to build

The 1.8.7 tarball you can download from guile's homepage won't build in our GnuCash mingw/MSYS environment.

First error is that our version of automake is too old. Guile requires 1.11, GnuCash still builds with 1.10 at the time of this writing. Luckily, this can easily be fixed by updating the version in defaults.sh and rebuilding the autotools/libtool packages.
Guile 1.8.7 no longer contains its own libltdl implementation. This is provided with libtool though. All it required to fix this was to add the proper paths to CPPFLAGS and LDFLAGS.
Also new is that guile now requires gmp. Another addition to CPPFLAGS and LDFLAGS solves this.
Next is libintl. GnuCash builds this as part of the Gnome packages. However, we pull in the gnome libraries after we build guile. This doesn't work. So the build script has to be modified to first do the gnome install and then build guile.
Guile 1.8.7 still recognizes the configure time option --disable-networking, yet it won't build on Windows if this option is set. So this option should be removed from the build script.
Next, all kinds of unresolved symbol errors pop up. To fix most of them, I looked at the source package of MSYS-guile-1.8.7. They apparently managed to build guile, so it provided a good starting point. I can't use their patches verbatim, because that would result in a guile package that depends on the MSYS environment. Their patch for config.in was very useful though. To build build with this patch, the configure script has to be rebuilt, using autoreconf. This in itself was a bit of a quest. It wouldn't work unless I redefined ACLOCAL and passed autoreconf a number of library paths.
I also learned from the MSYS-guile project that guile should be built with "-Wl,enable-auto-import" to avoid a number of linker warnings (which are treated as errors in our build process).

That was about all to get the library and executable to build. But then it really gets ugly. The next part of the guile build process uses the freshly compiled executable to setup other required bits. This fails miserably with a rather cryptic error

ERROR: In procedure scm_i_lreadparen: #<unknown port>:1:7: end of file

.

It took me quite a while to grasp this one. I found several threads on different mailing lists about the error, which where more or less helpful:

http://www.mail-archive.com/bug-guile@gnu.org/msg04711.html, which at some point links to http://lists-archives.org/mingw-users/14268-problem-with-argc-argv-under-msys.html, which in turn refers to http://thread.gmane.org/gmane.comp.gnu.mingw.msys/3719. The solution mentioned here, didn't apply in my case, but I got to understand the problem a little better.
Then I was lucky enough to stumble upon two thread in the mingw-devel list: Again on windows support and Again on windows support (2). These are two long threads on building guile on windows and the issues in it. I learned here that the build process uses a wrapper program around the guile executable. Confusingly, this wrapper is called guile.exe as well, yet it has issues on windows, that the actual guile.exe doesn't have. So I wrote a small patch to use that actual guile.exe instead of the wrapper during the build process.

Result: the guile build process completes, and the guile binary works - provided it can find all of its library dependencies of course.

guile -c '(use-modules (srfi srfi-39))'

runs with no problems.

slib

This is still problematic at this point.

guile -c "(use-modules (ice-9 slib)) (require 'printf)"

results in this error:

ERROR: In procedure open-file: ERROR: No such file or directory: "C:/GCDevel/guile/share/guile/1.8/slib/C:/GCDevel/guile/share/guile/1.8/slib/require" ABORT: (system error)</pre>

Obviously there's something wrong with the path guile uses to find the file require.scm.

I'm still investigating what happens here.

Difference between revisions of "Building on Windows"

Revision as of 18:41, 18 October 2013

Contents

A bit of history

Instructions for an (almost) automated build

Working on Gnucash

Alternative way to develop on a Windows machine

Notes

Error messages, Trace file

Debugging with gdb

install.sh

Console output and exetype

Problems, issues, comments

DLL install error

Missing file after extracting Open SSL on Windows XP Pro

Logitech QuickCam conflicts

Older information, mainly for reference

Guile 1.8

Getting it to build

slib

Navigation menu

Personal tools

Namespaces

Variants

Views

More

Search

Navigation

Related Sites

Contributing

Tools