Difference between revisions of "Windows/Old Notes"

Latest revision as of 14:43, 24 March 2017

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.

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.

intltool, libIDL, libart_lgpl, libgnomecanvas 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 [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 --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

Code for scheme modules

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

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 [3].

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:

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

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

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

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

• [11] Account tree
• [12] Register window
• [13] 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.

Text reports crash

Some text report crashed instantly, but on some other machines they worked fine. Same for graphical reports. Debugging is ongoing. When you run gnucash in gdb, the crash does reliably not occur the text reports.

What we currently know: GnuCash spits a warning ([14]), but does not crash because of it. It crashes because of something different (in WinAPI?) we cannot detect in gdb. isDebuggerPresent() might be true, but a breakpoint will only be set for fatal errors, so we cannot set a breakpoint. We also cannot start gnucash with --g-fatal-warnings though, as a standard win32 glib build aborts the application after a critical error [15].

The issue is described in this bug and a solution is committed in SVN's install.sh in r15213. Hopefully, these crashers are fixed now :) I think removal of c:\soft\regex, \guile, \tmp\guile-1.6.8 and \gnucash (the previous installation) is necessary. -- andi5

Thanks for the fix in r15213! Indeed I don't see any crash anymore, and even the graphical reports (wohoo!) work correctly. (The warning of [16] is still there, though.) --Cstim 10:50, 15 December 2006 (EST)

Creating a binary package

A script that copies everything that is needed for providing a binary has been added to SVN into packaging/win32. Its name is dist.sh and it will create the directory "dist" below the installation directory of gnucash, so by default the result will be copied to c:\soft\gnucash\dist .

Additionally, an input script to the Inno Setup Compiler has been added to packaging/win32. That one can be run after dist.sh has finished, and it should package up everything in the dist directory into a self-installing setup.exe file. Feel free to try that and report back whether it works.

r15224-error unzip: command not found - basically the environment isnt getting setup from custom.sh completely. in particular, function inst_unzip() from install.sh. Hfelton

Did you execute the commands install.sh printed after it finished? These will make both, your running MSYS shell as well as new ones, ready for dist.sh. You can easily see them if you rerun install.sh, but comment out add_step svn_up and add_step inst_gnucash in dist.shcustom.sh first, otherwise be prepared to wait again ;-) -- andi5

"unzip not found" has been fixed by r15244.

ive been modifying install.sh (adding profile.d/inno-setup) and im wondering who/where to submit changes. h 17:55, 19 December 2006 (EST)

As written in README or HACKING: Send message to the Mailing Lists gnucash-devel.

Sent to the list [17], applied in r15241.

i was unable to do the shortcuts described, but after the long-wait i WAS able to complete/test everything and it worked! steps i needed to do were: 1) manually create c:\soft\msys\etc\profile.d directory; 2) copy/paste the commands that got printed out due to the finish function which setup the environment variables into installer.sh (created manually inside profile.d); 3) open a new mingw-window (environment is ok now) and run dist.sh; 4) download/install the inno-setup-quickstart-pack (easier to use than generic innosetup); 5) run inst-tool and open the c:\soft\repos\packaging\win32\gnucash.iss file; 6) compile, then test-run/install gnucash in the 'normal' program_files location! only thing that sorta didnt work was that i tried running the tutorial and the doc-system was not installed... anyways - i think most of the initial-profile-issues would be cleared up with a few adjustments to the install.sh script (which cannot be run from the repos\packaging\win32 location directly because it tries to svn-up itself and fails).

1) is fixed in r15246 by printing the command. Automagic creation of /etc/profile.d/installer.sh has been rejected ([18]). 2) will stay necessary. dist.sh sets its environment since r15244 (see unzip above). 4) got obsoleted by inst_inno

Experimental packages:

http://gnucashw32.zip.io 
ftp://gnucashw32.zip.io:anonymous@gnucashw32.zip.io
or: 
http://gnucash.calmar.ws 
ftp://gnucash:win32@calmar.ws/httpdocs/win32

ok - i guess this is a creation-issue. im mentioning it here so that anyone outside the devel-mailing-list might notice it before trying to run the "nightly" build files. r15246 seems to be creating a 'working' system. the iss-file indeed compiles something that is 26mb, but it fails after printing the tip-of-the-day with an error-msg: GnuCash engine failed to initialize. aborting. also, the iss-file was located in 2 places, neither of which would be my initial guess: c/soft/gnucash and c/soft/BUILD/packaging/win32/gnucash. i figure it is not worthwhile to upload this exe-file anywhere yet. h 05:57, 22 December 2006 (EST)

There are different files matched by gnucash.iss*: gnucash.iss.in may lie where you checked_out/copied packaging/win32 and is not used at all. \gnucash\repos\packaging\win32\gnucash.iss.in is read by configure (config.status), variables are substituted and the result is written to \gnucash\build\packaging\win32\gnucash.iss. dist.sh copies this file to \gnucash, so that the Inno Setup Compiler will create the setup.exe there too.

For "engine not initialized", see below. From my POV we should not start nightly builds before main runtime problems have been solved. -- andi5

Hi, Hfelton since it's probably you, who is maybe willing to build 'nightly' packages (I can not really, because I'm a linux user first of all, and e.g. always startup MSwin spending hours there without beeing able to work on other stuff... at the same time, can't work. It would have to be a background-thing) Anyway, about that zip.io site. I just wanted to say, it would be possible on gnucash.calmar.ws to prevent the problem you mentioned on zip.io - There the user can get a directory listing (that win32 dir, I setup like it with an according .htaccess file, maybe that would work on your system as well), and that without ftp access. So they can't change anything there really, but still get folder-access. Only developers like you could. (I mean, there would be the need to remove the ftp link then and keeping the password secret or so.) That would actually prevent malicious packages to quite some degree. At least here (.ch) the download is quite faster as well. Probably I won't do any further builds in the near future, also because of the problems on my win2000 System I always have with it. Just some thoughts about it. Again, I wish you all a good year! Calmar

Runtime issues of binary package

I have completed install.sh; the installed gnucash.bat can be started from Start->Execute and gnucash will run fine, including all features that are available.

Now I'm working on the binary package. I have run dist.sh, followed by "ISCC.exe gnucash.iss", which created the 27MB setup.exe of gnucash. This can be installed and uninstalled just fine. However, when I run the gnucash.bat from that installation, the "Reports" menu does not appear. (Additionally, various error messages are printed into gnucash.trace.) After r15236, gnucash won't start up in this case but instead it will abort with the message "engine initialization failed". I'm trying to track down when the initialization fails, and when it doesn't.

i have not yet joined the mailing-lists [will soon], but there are definitely subtleties with this installation-process. my interest lies in the prior shell-scripts, but i can tell you that the iss-file needs some ispp-work applied to it, imho. ---begin soapbox--- iscc needs to make the app-name a one-time-variable, etc. until the script has been generalized, it is going to be a bit flaky. also, until a test-harness has been installed - ANY code can be a bit flaky. setting up a test-harness is hard work. ive spent a fair-amount of time just trying to understand the single-function quiet in the install.sh script because of subtleties in the trap-function of the mingw-shell that are coming to light via a mini test-harness. ---end soapbox--- h 16:28, 20 December 2006 (EST)

1. It works when running gnucash in the $prefix directory, from gnucash.bat that was generated by install.sh.
2. It fails appear when running gnucash in the installation directory where the setup.exe was installed, from gnucash.bat that was generated by setup.exe.
3. It fails when running gnucash from the $prefix/dist/ directory, when editing the gnucash.bat of step 1 to change all $prefix paths into $prefix/dist for the gnucash parts, leaving the other paths unchanged. The errors in gnucash.trace include the following:

Error: gnc_component_manager_init(): component manager already initialized
gnc_options_ui_initialize: assertion `optionTable == NULL' failed
plugin_services_init: assertion `services == NULL' failed
plugin_service_define: assertion `NULL == g_hash_table_lookup (services, type_str)' failed

• It works when moving the $prefix directory to some other name, and editing the gnucash.bat of step1 to change all $prefix paths accordingly for the gnucash parts, leaving the other paths unchanged. So the problem might be related to the file copying of dist.sh

Note that gnucash.trace, when compared to step 1, now has the error message "Warning: qof_session_load_backend(): failed to load gncqof-backend-qsf from $prefix/lib", which is understandable because the loading point of the QSF backend (lib/libqof/qof/qofbackend.c) is the very last place in gnucash where a hard-coded path is used instead of a relocatable solution.

• It fails when copying $prefix/* (everything from that directory) to /some/where and editing gnucash.bat. (It used to work once, but after r15236 it always failed in this case.) It fails regardsless of whether the target directory is below $prefix or not, and also regardless of "cp -r", or "cp -a", or the Windows explorer for copying, or using zip/unzip for copying.
  • Really really weird. If you make "mv $prefix foo" (and adapt gnucash.bat), it works, but if you make "mkdir foo; cp -r $prefix/* foo" (and adapt gnucash.bat), then it doesn't work.

Business as usual: Works for me. The only thing i needed is the oneliner in r15239. Will test on a vanilla computer tomorrow. -- andi5

The fix seems very good, but even with r15239 I still get the above problem. --Cstim 06:06, 21 December 2006 (EST)

i think the mv-command might be broken-slightly in mingw. i know that chmod doesnt seem to work. (i tried to manually create a new.sh file and mingw/windows would not let it execute unless i changed it to a *.bat or *.exe file) cygwin seems to have its own ideas, and tab-autocomplete is also unique to the two systems. i only mention cygwin in passing - i do not use it for anything other than curiosity here. -- h

I do not understand that, please be more specific why mv is broken (example & error message). What did you use to execute new.sh? Shebang is there? There is no executable bit on windows anyway.

r15248 has landed, please reevaluate. -- andi5

I installed it today on a older (400Mhz) win2000 box, and everything worked fine: Install/startup/report.... I installed it on a D: partition. I did not deeply check all the gnucash functions, so. Very nice, thanks!Calmar

Report error

Update: This seems to be a general bug, and is not related to the Windows port. See http://bugzilla.gnome.org/show_bug.cgi?id=410407. The problem appears to have been fixed for the Windows port in svn-r15673.

I have one invoice for which I cannot build a report and therefore I cannot print it. The report simply reads

Report error
An error occurred while running the report

I wish it could be more verbose. I have also noticed that the fancy invoice gives this same error for all my invoices (I have 10 so far). Revisions tested: r15522 and r15574.

On Linux (Debian, GnuCash 2.0.2 r14936) the report of this invoice is generated without problems, also fancy invoice.

Note: I also built r15574 on Debian and (contrary to what I stated before) it does exhibit the problem, so this is a general bug and not related to the Windows port. The current HEAD (r15639) still has this bug.

Please take a look at /tmp/gnucash.trace, where /tmp is something like C:\Documents and Settings\$user\Local Settings\Temp on Windows. Does that file contain a guile stacktrace? -- andi5

That file does not contain the word 'guile' or 'scm', but besides warnings there are two critical errors:

* CRIT <gnc.gui> gnc_search_param_prepend: assertion `param' failed

* CRIT <gnc.io> [gnc_http_cancel_requests()] ***Warning*** Find a gnome2 replacement for ghttp *******

On the command line in Debian I see what I think is a guile stacktrace, ending with

/usr/local/share/gnucash/guile-modules/gnucash/report/fancy-invoice.scm:158:19: Wrong type argument in position 1: #<swig-pointer GncAccountValue * 8921618>

I found that it is job-related. Invoices without a job print fine.

I also get this error in GnuCash 2.2.4 (built from r16997 on 2008-03-02). --Riaanvddool 05:09, 1 July 2008 (EDT)

Found the following stack trace in temp folder:

• WARN <qof.engine> [guid_init()] only got 2437 bytes.

The identifiers might not be very random.

• WARN <gnc.app-util> Could not spawn perl: Failed to execute child process (No such file or directory)
• WARN <Gdk> gdkselection-win32.c:1068: OpenClipboard failed: Invalid window handle.
• WARN <Gdk> gdkselection-win32.c:1068: OpenClipboard failed: Invalid window handle.
• CRIT <gnc.backend.file> commodity_ref_to_dom_tree: assertion `c' failed
• CRIT <Gtk> gtk_tree_model_row_has_child_toggled: assertion `path != NULL' failed
• WARN <Gdk> gdkselection-win32.c:1068: OpenClipboard failed: Invalid window handle.
• CRIT <gnc.backend.file> commodity_ref_to_dom_tree: assertion `c' failed
• WARN <Gdk> gdkselection-win32.c:1068: OpenClipboard failed: Invalid window handle.

Dates keep changing

I started entering information dating back to 1/1/07. Every account I have created I put in an opening balance dated on Jan 1. Now, the dates are all changed, some to 1/2 some to 1/3 and most to 1/4.

Filed at http://bugzilla.gnome.org/show_bug.cgi?id=405391 Can you attach a very simple example data file that shows this problem? In particular, we would like to have a look at the <ts:date>... lines of those transactions that seem to be changing dates. Anything unusual there should be noted, like a wrong date zone value or such.

(Side note: As we're all in different countries, using different date formats, you should explicitly say whether "1/4" refers to January 4 vs. April 1. Thanks.)

Fixed in r15472.