Re: Compiling GnuCash on Windows
Hello, Yesterday got compiled and running version of GC on Win32. Version: This copy was built from svn r15066 on 2006-11-01. I did little modifications to custom.sh from GTK_URL=$GNOME_WIN32_URL/gtk+/2.10/gtk+-2.10.3.zip GTK_DEV_URL=$GNOME_WIN32_URL/gtk+/2.10/gtk+-dev-2.10.3.zip to GTK_URL=$GNOME_WIN32_URL/gtk+/2.10/gtk+-2.10.6.zip GTK_DEV_URL=$GNOME_WIN32_URL/gtk+/2.10/gtk+-dev-2.10.6.zip This solved me the problem (I think so) with crashing on filesistem operations. Below are few more comments. With regards, Ivars Christian Stimming wrote: I'd like to hear whether these things work, in case you have some time to check them in detail: - Creating a new file (with default account hierarchy) Ok. - Creating more accounts in that file Ok. - Adding transactions to these accounts Ok. - running reports, particularly account summary, income statement, balance sheet Account Summary: OK Income Statement: OK Balance Sheet: OK - Changing some preferences (are these preserved when shutting down (without crashing) and starting again?) Ok. Other problems observed: - I use Latvian language and location; there are problems with entering/showing specific latvian characters; - Actions-Scheduled Transactions- FAILS with this backtrace on screen within GDB: GNU gdb 5.2.1 Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i686-pc-mingw32... (gdb) run Starting program: c:\gc\gnucash\bin/gnucash-bin.exe Program received signal SIGSEGV, Segmentation fault. 0x6b072b01 in _libmsvcrt_a_iname () (gdb) backtrace #0 0x6b072b01 in _libmsvcrt_a_iname () #1 0x100516f0 in _PRETTY_FUNCTION__.28 () #2 0x6b073034 in _libmsvcrt_a_iname () #3 0x6b046dd4 in __RUNTIME_PSEUDO_RELOC_LIST__ () #4 0x0077a51c in ?? () #5 0x005fc9f4 in ?? () #6 0x005e66f7 in ?? () #7 0x005e5b39 in ?? () #8 0x005e65eb in ?? () #9 0x005e66d6 in ?? () #10 0x00778000 in ?? () #11 0x63054ab6 in gnc_ui_scheduled_xaction_dialog_create () at dialog-scheduledxaction.c:1250 #12 0x005e3935 in ?? () #13 0x005f6f35 in ?? () #14 0x005f7cde in ?? () #15 0x005f7f56 in ?? () #16 0x6048b824 in _libws2_32_a_iname () #17 0x005e3935 in ?? () #18 0x005f6f35 in ?? () #19 0x005f7cde in ?? () #20 0x005f7f56 in ?? () #21 0x606999e5 in _libws2_32_a_iname () #22 0x6058acec in _libws2_32_a_iname () #23 0x6058aff5 in _libws2_32_a_iname () #24 0x605774a2 in _libws2_32_a_iname () #25 0x005e3935 in ?? () #26 0x005f6b66 in ?? () #27 0x005f7a3c in ?? () #28 0x005f7f56 in ?? () #29 0x60699b74 in _libws2_32_a_iname () #30 0x60574651 in _libws2_32_a_iname () #31 0x6057593d in _libws2_32_a_iname () #32 0x6b07098e in _libmsvcrt_a_iname () #33 0x1001d8f7 in gpa_radiobutton_update () #34 0x1001edcb in gpa_p2f_entry_changed_cb () #35 0x1001efaa in gp_gc_set_font () #36 0x60574eae in _libws2_32_a_iname () #37 0x00784a12 in ?? () #38 0x00401746 in inner_main (closure=0x0, argc=1, argv=0xd16ea8) at gnucash-bin.c:493 #39 0x65e2564d in scm_boot_guile (argc=1, argv=0xd16ea8, main_func=0x401600 inner_main, closure=0x0) at init.c:635 #40 0x00401e26 in main (argc=1, argv=0xd16ea8) at gnucash-bin.c:549 (gdb) - I also can't build gnucash.pot file as proposed by doc/TRANSLATION_HOWTO: [EMAIL PROTECTED] ~ $ cd /c/gc/repos/po/ [EMAIL PROTECTED] /c/gc/repos/po $ make gnucash.pot INTLTOOL_EXTRACT=../intltool-extract srcdir=. ../intltool-update --gettext-package gnucash --pot *** The intltool-extract script wasn't found! *** Without it, intltool-update can not generate files. Also, in the command prompt window is the following: gnucash: [E] Failed to fork child process. This is probably because gnucash tries to save the file in compressed form, which requires a separate gzip process that won't work on windows. In short, in the preferences please uncheck the checkbox under General - File - Compress file. Does saving work, then? Previously I have had problem to open data file created on Knoppix with GC 2.0.1. When I unziped that data file, I was able to open it on Win32 with GC 2.0.2. Is there a way to generate a backtrace in Windows? Yes, if you install gdb. It's available somewhere on mingw.org. Then you need to modify the gnucash startup script so that it calls gdb instead of gnucash.exe. Then, in gdb you start gnucash by run. This is explained in the file HACKING as well. Is the backtrace given above the one, which is needed? I mean, did I do correctly, to get backtarce? Thanks a lot, Christian ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel ___
Re: Compiling GnuCash on Windows
Ivars Grinbergs wrote: - Actions-Scheduled Transactions- FAILS with this backtrace on screen within GDB: Sorry, I mean Actions-Scheduled Transactions-Scheduled Transaction Editor ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Compiling GnuCash on Windows
Hi, Am Donnerstag, den 02.11.2006, 13:31 +0200 schrieb Ivars Grinbergs: Hello, Yesterday got compiled and running version of GC on Win32. Version: This copy was built from svn r15066 on 2006-11-01. Too bad, you missed some fixes I submitted yesterday. You might try remove your gnome installation directory and rerun install.sh with recent packaging/win32 directory. You should also check for an _empty_ install-sh (hyphen) file in your repository and remove it if necessary (will fix it soon). Meanwhile, do not put install.sh into a parent directory of the repository. I did little modifications to custom.sh from GTK_URL=$GNOME_WIN32_URL/gtk+/2.10/gtk+-2.10.3.zip GTK_DEV_URL=$GNOME_WIN32_URL/gtk+/2.10/gtk+-dev-2.10.3.zip to GTK_URL=$GNOME_WIN32_URL/gtk+/2.10/gtk+-2.10.6.zip GTK_DEV_URL=$GNOME_WIN32_URL/gtk+/2.10/gtk+-dev-2.10.6.zip This solved me the problem (I think so) with crashing on filesistem operations. Yeah, fixed in r15076. Below are few more comments. With regards, Ivars Christian Stimming wrote: I'd like to hear whether these things work, in case you have some time to check them in detail: Did you run gnucash from the MSYS shell or gnucash.bat? [successes snip] Other problems observed: - I use Latvian language and location; there are problems with entering/showing specific latvian characters; Please be more specific. Is there a way for us (non-latvians) to reproduce this? BTW, we still need to fix both, the installation and usage of our localizations. - Actions-Scheduled Transactions- FAILS with this backtrace on screen within GDB: GNU gdb 5.2.1 Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i686-pc-mingw32... (gdb) run Starting program: c:\gc\gnucash\bin/gnucash-bin.exe Program received signal SIGSEGV, Segmentation fault. 0x6b072b01 in _libmsvcrt_a_iname () (gdb) backtrace #0 0x6b072b01 in _libmsvcrt_a_iname () #1 0x100516f0 in _PRETTY_FUNCTION__.28 () #2 0x6b073034 in _libmsvcrt_a_iname () #3 0x6b046dd4 in __RUNTIME_PSEUDO_RELOC_LIST__ () #4 0x0077a51c in ?? () #5 0x005fc9f4 in ?? () #6 0x005e66f7 in ?? () #7 0x005e5b39 in ?? () #8 0x005e65eb in ?? () #9 0x005e66d6 in ?? () #10 0x00778000 in ?? () #11 0x63054ab6 in gnc_ui_scheduled_xaction_dialog_create () at dialog-scheduledxaction.c:1250 #12 0x005e3935 in ?? () #13 0x005f6f35 in ?? () #14 0x005f7cde in ?? () #15 0x005f7f56 in ?? () #16 0x6048b824 in _libws2_32_a_iname () #17 0x005e3935 in ?? () #18 0x005f6f35 in ?? () #19 0x005f7cde in ?? () #20 0x005f7f56 in ?? () #21 0x606999e5 in _libws2_32_a_iname () #22 0x6058acec in _libws2_32_a_iname () #23 0x6058aff5 in _libws2_32_a_iname () #24 0x605774a2 in _libws2_32_a_iname () #25 0x005e3935 in ?? () #26 0x005f6b66 in ?? () #27 0x005f7a3c in ?? () #28 0x005f7f56 in ?? () #29 0x60699b74 in _libws2_32_a_iname () #30 0x60574651 in _libws2_32_a_iname () #31 0x6057593d in _libws2_32_a_iname () #32 0x6b07098e in _libmsvcrt_a_iname () #33 0x1001d8f7 in gpa_radiobutton_update () #34 0x1001edcb in gpa_p2f_entry_changed_cb () #35 0x1001efaa in gp_gc_set_font () #36 0x60574eae in _libws2_32_a_iname () #37 0x00784a12 in ?? () #38 0x00401746 in inner_main (closure=0x0, argc=1, argv=0xd16ea8) at gnucash-bin.c:493 #39 0x65e2564d in scm_boot_guile (argc=1, argv=0xd16ea8, main_func=0x401600 inner_main, closure=0x0) at init.c:635 #40 0x00401e26 in main (argc=1, argv=0xd16ea8) at gnucash-bin.c:549 (gdb) You have to admit that this stack trace is not extraordinary useful ;-) But yesterday I managed to improve, maybe you can try to do the same? Here is what I did: * download and unpack `pd' and `MMP' from http://www.trapkit.de, you will need the Microsoft .NET Framework Version 2.0 to run the latter * make gnucash crash within gdb * determine the PID of the running gnucash-bin process (Ctrl+Alt+Del) * open a shell and enter `pd -p $pid my.dump', where $pid is your pid * open mmp, open my.dump, let it parse it (click away errors you get, ignore please wait dialogs that do not go away and also crashes when you try to close mmp after your work) * see frame #4, it says 0x0077a51c... try to find the dll that got mapped there and also its base address (one of the first columns) * enter `add-symbol-file $mydll $myaddr' into gdb, where $mydll might be libgncmod-gnome-utils-0.dll or such, and myaddr the base address mmp told you; confirm with y * bt again Success? Any suggestions how to ease this process? - I also can't build gnucash.pot file as proposed by doc/TRANSLATION_HOWTO: [EMAIL PROTECTED] ~ $ cd /c/gc/repos/po/ [EMAIL PROTECTED] /c/gc/repos/po $ make gnucash.pot
Re: GC architecture for backends
2006/11/1, Derek Atkins [EMAIL PROTECTED]: Quoting Daniel Espinosa [EMAIL PROTECTED]: Also, we'll need to make changes to handle the fact that file:// should get redirected to sqlite:// -- but the code will need to test the file first to see what kind of file it is, so that File - Open does the right thing. I.e., the fact that we're using SQLite should get hidden from the user when we migrate to it. I think the URI mus be gda:// or db://, think that gda is wrapper for many DB backends not just sqlite. At some level we need to be able to specify what kind of database is sitting behind there. At SOME point we need to know how to specify a filename for SQLite vs. a host/port/user/password for PG. So clearly there's some differentiation there. Isn't the case for GDA, when you create a DSN, you can use this name to connect: you just need to specify the DSN, user, password and some options (read only for example) see the libgda.h file where you'll find some convenient functions to easy use GDA and quick do some very common task. But this is irrelevant to what I meant. What the user types into the File-Open dialog does not need to be the string that gets passed the GDA. If you have an option to connect or open a DSN the URI could be: gda://gnucash:username:password With a gnomedb-login widget you can select a predefined DNS, get username and password, and thats all you can pass it to the QOF beggin session function to open the back end. I'm just pointing out that we need to intercept that input and handle it appropriately, which may mean adjusting the actual string and perhaps calling the XML or GDA-with-SQLite backends. In the event that GC will use just SQLite or other DB engines, you don't need a special intercept, I think the dialog *must* allways show a gnomedb-login widget to select the DSN, write a user and a password, and Go! -- Trabajar, la mejor arma para tu superación de grano en grano, se hace la arena (R) (entrámite, pero para los cuates: LIBRE) ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Compiling GnuCash on Windows
Andreas Köhler wrote: Did you run gnucash from the MSYS shell or gnucash.bat? From MSYS shell, within gdb (but it works from shell without gdb, too). [successes snip] Other problems observed: - I use Latvian language and location; there are problems with entering/showing specific latvian characters; Please be more specific. Is there a way for us (non-latvians) to reproduce this? BTW, we still need to fix both, the installation and usage of our localizations. I shall check this later how to do this on pure WinXP, since I use third party software for keyboard management. You have to admit that this stack trace is not extraordinary useful ;-) But yesterday I managed to improve, maybe you can try to do the same? Here is what I did: * download and unpack `pd' and `MMP' from http://www.trapkit.de, you will need the Microsoft .NET Framework Version 2.0 to run the latter * make gnucash crash within gdb * determine the PID of the running gnucash-bin process (Ctrl+Alt+Del) * open a shell and enter `pd -p $pid my.dump', where $pid is your pid * open mmp, open my.dump, let it parse it (click away errors you get, ignore please wait dialogs that do not go away and also crashes when you try to close mmp after your work) * see frame #4, it says 0x0077a51c... try to find the dll that got mapped there and also its base address (one of the first columns) * enter `add-symbol-file $mydll $myaddr' into gdb, where $mydll might be libgncmod-gnome-utils-0.dll or such, and myaddr the base address mmp told you; confirm with y * bt again Success? I shall try it out as soon as possible, will come back with results. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Compiling GnuCash on Windows
Andreas Köhler wrote: You have to admit that this stack trace is not extraordinary useful ;-) But yesterday I managed to improve, maybe you can try to do the same? Here is what I did: * download and unpack `pd' and `MMP' from http://www.trapkit.de, you will need the Microsoft .NET Framework Version 2.0 to run the latter * make gnucash crash within gdb * determine the PID of the running gnucash-bin process (Ctrl+Alt+Del) * open a shell and enter `pd -p $pid my.dump', where $pid is your pid * open mmp, open my.dump, let it parse it (click away errors you get, ignore please wait dialogs that do not go away and also crashes when you try to close mmp after your work) * see frame #4, it says 0x0077a51c... try to find the dll that got mapped there and also its base address (one of the first columns) * enter `add-symbol-file $mydll $myaddr' into gdb, where $mydll might be libgncmod-gnome-utils-0.dll or such, and myaddr the base address mmp told you; confirm with y * bt again Success? hopefully :) here is what I have got: #0 0x6b072b01 in _libmsvcrt_a_iname () #1 0x100516f0 in _PRETTY_FUNCTION__.28 () #2 0x6b073034 in _libmsvcrt_a_iname () #3 0x6b046dd4 in __RUNTIME_PSEUDO_RELOC_LIST__ () #4 0x0077a51c in _end__ () #5 0x005fc9f4 in libgncmod_gnome_utils_0_dll_iname () #6 0x005e66f7 in libgncmod_gnome_utils_0_dll_iname () #7 0x005e5b39 in libgncmod_gnome_utils_0_dll_iname () #8 0x005e65eb in libgncmod_gnome_utils_0_dll_iname () #9 0x005e66d6 in libgncmod_gnome_utils_0_dll_iname () #10 0x00778000 in ?? () #11 0x63054ab6 in gnc_ui_scheduled_xaction_dialog_create () at dialog-scheduledxaction.c:1250 #12 0x005e3935 in libgncmod_gnome_utils_0_dll_iname () #13 0x005f6f35 in libgncmod_gnome_utils_0_dll_iname () #14 0x005f7cde in libgncmod_gnome_utils_0_dll_iname () #15 0x005f7f56 in libgncmod_gnome_utils_0_dll_iname () #16 0x6048b824 in _libws2_32_a_iname () #17 0x005e3935 in libgncmod_gnome_utils_0_dll_iname () #18 0x005f6f35 in libgncmod_gnome_utils_0_dll_iname () #19 0x005f7cde in libgncmod_gnome_utils_0_dll_iname () #20 0x005f7f56 in libgncmod_gnome_utils_0_dll_iname () #21 0x606999e5 in _libws2_32_a_iname () #22 0x6058acec in _libws2_32_a_iname () #23 0x6058aff5 in _libws2_32_a_iname () #24 0x605774a2 in _libws2_32_a_iname () #25 0x005e3935 in libgncmod_gnome_utils_0_dll_iname () #26 0x005f6b66 in libgncmod_gnome_utils_0_dll_iname () #27 0x005f7a3c in libgncmod_gnome_utils_0_dll_iname () #28 0x005f7f56 in libgncmod_gnome_utils_0_dll_iname () #29 0x60699b74 in _libws2_32_a_iname () #30 0x60574651 in _libws2_32_a_iname () #31 0x6057593d in _libws2_32_a_iname () #32 0x6b07098e in _libmsvcrt_a_iname () #33 0x1001d8f7 in gpa_radiobutton_update () #34 0x1001edcb in gpa_p2f_entry_changed_cb () #35 0x1001efaa in gp_gc_set_font () #36 0x60574eae in _libws2_32_a_iname () #37 0x00784a12 in gnc_option_set_ui_widget_commodity (option=0x40448e, page_box=0x0, tooltips=0x0, name=0x65e25134 \201ūt!, documentation=0x0, enclosing=0x404868, packed=0x22fca8) at dialog-options.c:1668 #38 0x00401746 in inner_main (closure=0x0, argc=1, argv=0xd16ea8) at gnucash-bin.c:493 #39 0x65e2564d in scm_boot_guile (argc=1, argv=0xd16ea8, main_func=0x401600 inner_main, closure=0x0) at init.c:635 #40 0x00401e26 in main (argc=1, argv=0xd16ea8) at gnucash-bin.c:549 wbr Ivars ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: GC architecture for backends
On Thu, 2006-02-11 at 08:40 -0600, Daniel Espinosa wrote: 2006/11/1, Derek Atkins [EMAIL PROTECTED]: Quoting Daniel Espinosa [EMAIL PROTECTED]: Also, we'll need to make changes to handle the fact that file:// should get redirected to sqlite:// -- but the code will need to test the file first to see what kind of file it is, so that File - Open does the right thing. I.e., the fact that we're using SQLite should get hidden from the user when we migrate to it. I think the URI mus be gda:// or db://, think that gda is wrapper for many DB backends not just sqlite. At some level we need to be able to specify what kind of database is sitting behind there. At SOME point we need to know how to specify a filename for SQLite vs. a host/port/user/password for PG. So clearly there's some differentiation there. Isn't the case for GDA, when you create a DSN, you can use this name to connect: you just need to specify the DSN, user, password and some options (read only for example) see the libgda.h file where you'll find some convenient functions to easy use GDA and quick do some very common task. But this is irrelevant to what I meant. What the user types into the File-Open dialog does not need to be the string that gets passed the GDA. If you have an option to connect or open a DSN the URI could be: gda://gnucash:username:password With a gnomedb-login widget you can select a predefined DNS, get username and password, and thats all you can pass it to the QOF beggin session function to open the back end. I'm just pointing out that we need to intercept that input and handle it appropriately, which may mean adjusting the actual string and perhaps calling the XML or GDA-with-SQLite backends. In the event that GC will use just SQLite or other DB engines, you don't need a special intercept, I think the dialog *must* allways show a gnomedb-login widget to select the DSN, write a user and a password, and Go! I haven't thought through all of the issues around connections, but I don't think we want to use predefined DSNs. A user shouldn't have to set up the GC DSN with an external tool in order to use that DSN within gnucash. Phil ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Compiling GnuCash on Windows
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 For me on win2000/SP4 with r15078 and the updated gnome packages according to the recent commits in custom.sh, I get these: - Creating a new file (with default account hierarchy) Works for me just fine. The account hierarchy druid comes up and gives all the locale=C choices that are shipped with gnucash. - Creating more accounts in that file Works. - Adding transactions to these accounts Works. - running reports, particularly account summary, income statement, balance sheet Doesn't work. I tried to run gnucash under gdb, http://wiki.gnucash.org/wiki/Windows#gdb , and surprisingly enough then it works! All of the text reports will simply work when running under gdb... sigh. - Saving to file Works just fine as well, probably due to the recent gtk upgrade. Also, in the command prompt window is the following: gnucash: [E] Failed to fork child process. This is probably because gnucash tries to save the file in compressed form, which requires a separate gzip process that won't work on windows. In short, in the preferences please uncheck the checkbox under General - File - Compress file. Does saving work, then? I wonder if we should just disable this feature on win32? The feature is already disabled on windows, see io-gncxml-v2.c:1243. I tried to find the place that's causing this failed to fork message, but apparently it doesn't come from within gnucash. At least we don't have that string anywhere, and the only fork() that gnucash uses is in io-gncxml-v2.c which is unused on windows. So I have no idea where this comes from, and I'd simply ignore it for now. Christian -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.1 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQCUAwUBRUoq2GXAi+BfhivFAQJp2gP4j7hgq6uSk5MZ79RXe3oRp0die6PKdpah GaFYxStJqCEdTNbSdMQmh1Or/W4zaK7l/h9tJ71CWMErwcmg+CcVGe91K6x032ZY 4hK8ZuP7viFSm7YekEyFlwbMbSm5bSc3eG+ReB8l4EPQ44tBWFmdFfJspe3iaD4h BgDpzKJatw== =sFD8 -END PGP SIGNATURE- ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Compiling GnuCash on Windows
Hi, Ivars Grinbergs wrote: Andreas Köhler wrote: You have to admit that this stack trace is not extraordinary useful ;-) But yesterday I managed to improve, maybe you can try to do the same? Here is what I did: * download and unpack `pd' and `MMP' from http://www.trapkit.de, you will need the Microsoft .NET Framework Version 2.0 to run the latter * make gnucash crash within gdb * determine the PID of the running gnucash-bin process (Ctrl+Alt+Del) * open a shell and enter `pd -p $pid my.dump', where $pid is your pid * open mmp, open my.dump, let it parse it (click away errors you get, ignore please wait dialogs that do not go away and also crashes when you try to close mmp after your work) * see frame #4, it says 0x0077a51c... try to find the dll that got mapped there and also its base address (one of the first columns) * enter `add-symbol-file $mydll $myaddr' into gdb, where $mydll might be libgncmod-gnome-utils-0.dll or such, and myaddr the base address mmp told you; confirm with y * bt again Success? hopefully :) here is what I have got: #0 0x6b072b01 in _libmsvcrt_a_iname () #1 0x100516f0 in _PRETTY_FUNCTION__.28 () #2 0x6b073034 in _libmsvcrt_a_iname () #3 0x6b046dd4 in __RUNTIME_PSEUDO_RELOC_LIST__ () #4 0x0077a51c in _end__ () #5 0x005fc9f4 in libgncmod_gnome_utils_0_dll_iname () #6 0x005e66f7 in libgncmod_gnome_utils_0_dll_iname () #7 0x005e5b39 in libgncmod_gnome_utils_0_dll_iname () #8 0x005e65eb in libgncmod_gnome_utils_0_dll_iname () #9 0x005e66d6 in libgncmod_gnome_utils_0_dll_iname () #10 0x00778000 in ?? () #11 0x63054ab6 in gnc_ui_scheduled_xaction_dialog_create () at dialog-scheduledxaction.c:1250 #12 0x005e3935 in libgncmod_gnome_utils_0_dll_iname () #13 0x005f6f35 in libgncmod_gnome_utils_0_dll_iname () #14 0x005f7cde in libgncmod_gnome_utils_0_dll_iname () #15 0x005f7f56 in libgncmod_gnome_utils_0_dll_iname () #16 0x6048b824 in _libws2_32_a_iname () #17 0x005e3935 in libgncmod_gnome_utils_0_dll_iname () #18 0x005f6f35 in libgncmod_gnome_utils_0_dll_iname () #19 0x005f7cde in libgncmod_gnome_utils_0_dll_iname () #20 0x005f7f56 in libgncmod_gnome_utils_0_dll_iname () #21 0x606999e5 in _libws2_32_a_iname () #22 0x6058acec in _libws2_32_a_iname () #23 0x6058aff5 in _libws2_32_a_iname () #24 0x605774a2 in _libws2_32_a_iname () #25 0x005e3935 in libgncmod_gnome_utils_0_dll_iname () #26 0x005f6b66 in libgncmod_gnome_utils_0_dll_iname () #27 0x005f7a3c in libgncmod_gnome_utils_0_dll_iname () #28 0x005f7f56 in libgncmod_gnome_utils_0_dll_iname () #29 0x60699b74 in _libws2_32_a_iname () #30 0x60574651 in _libws2_32_a_iname () #31 0x6057593d in _libws2_32_a_iname () #32 0x6b07098e in _libmsvcrt_a_iname () #33 0x1001d8f7 in gpa_radiobutton_update () #34 0x1001edcb in gpa_p2f_entry_changed_cb () #35 0x1001efaa in gp_gc_set_font () #36 0x60574eae in _libws2_32_a_iname () #37 0x00784a12 in gnc_option_set_ui_widget_commodity (option=0x40448e, page_box=0x0, tooltips=0x0, name=0x65e25134 \201ūt!, documentation=0x0, enclosing=0x404868, packed=0x22fca8) at dialog-options.c:1668 #38 0x00401746 in inner_main (closure=0x0, argc=1, argv=0xd16ea8) at gnucash-bin.c:493 #39 0x65e2564d in scm_boot_guile (argc=1, argv=0xd16ea8, main_func=0x401600 inner_main, closure=0x0) at init.c:635 #40 0x00401e26 in main (argc=1, argv=0xd16ea8) at gnucash-bin.c:549 sorry for the answer in a hurry. Can you please double-check that 1) you select the one line in mappings within mmp such that mapping_start = 0x0077a51c mapping_end 2) $mydll is the basename (the part after the last backslash) in the mapped_from column 3) $myaddr is the mapping_start? So yes, the backtrace looks better, but still lacks real debugging information (function names, line numbers). I expect you did not change install.sh so that it either does not include debug symbols or strips the binaries... Go go, well done so far! -- andi5 -- GMX DSL-Flatrate 0,- Euro* - Überall, wo DSL verfügbar ist! NEU: Jetzt bis zu 16.000 kBit/s! http://www.gmx.net/de/go/dsl ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Compiling GnuCash on Windows
On Thu, Nov 02, 2006 at 06:28:56PM +0100, Christian Stimming wrote: Also, in the command prompt window is the following: gnucash: [E] Failed to fork child process. This is probably because gnucash tries to save the file in compressed form, which requires a separate gzip process that won't work on windows. In short, in the preferences please uncheck the checkbox under General - File - Compress file. Does saving work, then? I wonder if we should just disable this feature on win32? The feature is already disabled on windows, see io-gncxml-v2.c:1243. I tried to find the place that's causing this failed to fork message, but apparently it doesn't come from within gnucash. At least we don't have that string anywhere, and the only fork() that gnucash uses is in io-gncxml-v2.c which is unused on windows. So I have no idea where this comes from, and I'd simply ignore it for now. That's process.scm which is run during price-quote retrieval. Perhaps guile's (primitive-fork) doesn't work on win32. -chris ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: GC architecture for backends
On Thu, Nov 02, 2006 at 12:25:17PM -0500, Phil Longstaff wrote: On Thu, 2006-02-11 at 08:40 -0600, Daniel Espinosa wrote: 2006/11/1, Derek Atkins [EMAIL PROTECTED]: Quoting Daniel Espinosa [EMAIL PROTECTED]: Also, we'll need to make changes to handle the fact that file:// should get redirected to sqlite:// -- but the code will need to test the file first to see what kind of file it is, so that File - Open does the right thing. I.e., the fact that we're using SQLite should get hidden from the user when we migrate to it. I think the URI mus be gda:// or db://, think that gda is wrapper for many DB backends not just sqlite. At some level we need to be able to specify what kind of database is sitting behind there. At SOME point we need to know how to specify a filename for SQLite vs. a host/port/user/password for PG. So clearly there's some differentiation there. Isn't the case for GDA, when you create a DSN, you can use this name to connect: you just need to specify the DSN, user, password and some options (read only for example) see the libgda.h file where you'll find some convenient functions to easy use GDA and quick do some very common task. But this is irrelevant to what I meant. What the user types into the File-Open dialog does not need to be the string that gets passed the GDA. If you have an option to connect or open a DSN the URI could be: gda://gnucash:username:password With a gnomedb-login widget you can select a predefined DNS, get username and password, and thats all you can pass it to the QOF beggin session function to open the back end. I'm just pointing out that we need to intercept that input and handle it appropriately, which may mean adjusting the actual string and perhaps calling the XML or GDA-with-SQLite backends. In the event that GC will use just SQLite or other DB engines, you don't need a special intercept, I think the dialog *must* allways show a gnomedb-login widget to select the DSN, write a user and a password, and Go! I haven't thought through all of the issues around connections, but I don't think we want to use predefined DSNs. A user shouldn't have to set up the GC DSN with an external tool in order to use that DSN within gnucash. Phil At least for an initial implementation, I recommend letting the external tools handle DSN setup. The most general setups (i.e. anything other than sqllite) will probably require external configuration anyway. Once it's working, we can worry about streamlining setup for the simple cases. -chris ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: GC architecture for backends
Quoting Chris Shoemaker [EMAIL PROTECTED]: I haven't thought through all of the issues around connections, but I don't think we want to use predefined DSNs. A user shouldn't have to set up the GC DSN with an external tool in order to use that DSN within gnucash. Phil At least for an initial implementation, I recommend letting the external tools handle DSN setup. The most general setups (i.e. anything other than sqllite) will probably require external configuration anyway. Once it's working, we can worry about streamlining setup for the simple cases. Except for SQLite I don't have a strong opinion about DSN setup. However, for SQLite I think Gnucash needs to control the whole interaction and be able to force GDA to use SQLite. We (read: I) want the SQLite backend to replace the XML-File backend and become the new File Backend... -chris -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH [EMAIL PROTECTED]PGP key available ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
gnucash 2 at FINK
Still no signs of life... __ Check out the New Yahoo! Mail - Fire up a more powerful email and get things done faster. (http://advision.webevents.yahoo.com/mailbeta) ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: gnucash 2 at FINK
--On November 2, 2006 12:01:43 -0800 Bob Hunter [EMAIL PROTECTED] wrote: Still no signs of life... Sébastien Maret put together description files to build gnucash under Fink in August: http://fink.cvs.sourceforge.net/fink/experimental/bmaret/finkinfo/ I was succesful in building it this way, but I couldn't get the online quotes to work. I think Dave Reiser has been working on finishing it up. Now a lot of the reason it's slow to arrive in Fink is because of the multi-tree setup, with crypto and experimental. Many of gnucash's dependencies are themselves stuck in experimental, so it's gonna be a while before a binary package is available. You can help! You can do so by building the experimental packages and reporting on your success or lack thereof. If you *really* need gnucash 2 *now*, building it in macports works very well. It takes no more than 1GB -- that's about a dollar worth of a laptop hard drive -- and it builds in less than 8 hours on my 4-year-old machine. I'm assuming you have the developer tools installed, because after all you're subscribed to the devel list... -- Guillaume Lessard [EMAIL PROTECTED] ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: GC, QOF and queries
Quoting Phil Longstaff [EMAIL PROTECTED]: I have started working on a gda backend and am starting with a QofQuery - SQL translator. I assume no one else has such a beast (there is a SQL - QofQuery translator as part of QOF. When we get an SQL backend, it won't make sense to translate SQL - QofQuery - SQL). I have also looked at the pattern of queries. When GC starts, there is only one query - for bills which need to be paid. There is no query for the account tree, for example. GC must assume that session_begin loads the account tree. The PG Backend has a sample Query - SQL converter, but it's very limited -- it only does Transaction (Split) searches. Is this expected behaviour? I had assumed that everything would be queried for. This is expected behavior. Take a look at the PG Backend. All of the accounts are expected to get loaded at start time. From the business side, the Tax Tables and Terms are also expected to get loaded at start time. Not everything gets loaded by a query. Secondly, I looked at the begin/commit edit behaviour when an account was being created. There was a *lot* of begin/commit activity on the commodity, including some cases of begin/commit/commit. Is this expected behaviour? Begin/Commit can be nested (and indeed SHOULD be nested, IMNSHO).. However the begins and commits should be balanced. If they are not balanced then that is a bug. Only the final commit() should push the data out to the database. Phil -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH [EMAIL PROTECTED]PGP key available ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: gnucash 2 at FINK
Bob Hunter wrote: Still no signs of life... True. I've run into dependency issues. I (rightfully) don't have commit access to fink, so I need to have someone review the submissions. There are questions about how well new and old versions of gwenhywfar and aqbanking get along side by side in the distribution. I am making some progress, but it is slower than I anticipated because of my unfamiliarity with resolving version upgrades that are as far apart as gwen and aqbanking are for fink, while allowing gnucash 1.8.x to still be available as it was. Dave -- David Reiser [EMAIL PROTECTED] ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: GC, QOF and queries
On Thu, 2006-02-11 at 16:14 -0500, Derek Atkins wrote: Quoting Phil Longstaff [EMAIL PROTECTED]: I have started working on a gda backend and am starting with a QofQuery - SQL translator. I assume no one else has such a beast (there is a SQL - QofQuery translator as part of QOF. When we get an SQL backend, it won't make sense to translate SQL - QofQuery - SQL). I have also looked at the pattern of queries. When GC starts, there is only one query - for bills which need to be paid. There is no query for the account tree, for example. GC must assume that session_begin loads the account tree. The PG Backend has a sample Query - SQL converter, but it's very limited -- it only does Transaction (Split) searches. OK. I'll see if there is anything I can borrow from it. This is expected behavior. Take a look at the PG Backend. All of the accounts are expected to get loaded at start time. From the business side, the Tax Tables and Terms are also expected to get loaded at start time. Not everything gets loaded by a query. OK Secondly, I looked at the begin/commit edit behaviour when an account was being created. There was a *lot* of begin/commit activity on the commodity, including some cases of begin/commit/commit. Is this expected behaviour? Begin/Commit can be nested (and indeed SHOULD be nested, IMNSHO).. However the begins and commits should be balanced. If they are not balanced then that is a bug. Only the final commit() should push the data out to the database. There are 2 commits because, for example, gnc_commodity_commit_edit() calls qof_commit_edit() and then qof_commit_edit_part2(). qof_commit_edit() calls the backend commit if the editlevel is 0 and the instance is dirty. qof_commit_edit_part2() always calls the backend commit. Phil ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: GC, QOF and queries
Quoting Phil Longstaff [EMAIL PROTECTED]: OK. I'll see if there is anything I can borrow from it. I doubt there is, except as a prototype.. Secondly, I looked at the begin/commit edit behaviour when an account was being created. There was a *lot* of begin/commit activity on the commodity, including some cases of begin/commit/commit. Is this expected behaviour? Begin/Commit can be nested (and indeed SHOULD be nested, IMNSHO).. However the begins and commits should be balanced. If they are not balanced then that is a bug. Only the final commit() should push the data out to the database. There are 2 commits because, for example, gnc_commodity_commit_edit() calls qof_commit_edit() and then qof_commit_edit_part2(). qof_commit_edit() calls the backend commit if the editlevel is 0 and the instance is dirty. qof_commit_edit_part2() always calls the backend commit. This seems like a bug. The backend commit should only get called once. If it's getting called twice, that's a bug. Phil -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH [EMAIL PROTECTED]PGP key available ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: GC, QOF and queries
On Thu, Nov 02, 2006 at 08:47:30AM -0500, Phil Longstaff wrote: I have started working on a gda backend and am starting with a QofQuery - SQL translator. Have you looked at just directly using the GdaQuery objects? You can constuct an abstract query out of GdaQueryFieldFields, GdaQueryFieldValues and such. Then, libgda will emit the provider-specific SQL for that query. To be frank, IMO, GdaQuery is a better data model for queries than QofQuery. By better, I mean more appropriate for GnuCash. I think it's very unfortunate that GnuCash uses its own home-grown object-agnostic query representation. Someone else will probably disagree. But, if you re-parented GnuCash's engine objects with a GnuCash-sepcific GncObject (even with GValue parameters, maybe), and implemented the QofQuery functionality by generating a GdaQuery, you would be my hero. But that's probably more work than you were hoping for. *sigh* Anyway, try to avoid writing the SQL emitter, if you can. -chris ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: GC architecture for backends
I would suggest that those wishing to use a database other than SQLite will have to know what they are doing so can define the DSN externally and so when opening a book if its name is not in the data source list create a SQLite DSN and add it to the data source list. Regards, Chris On Thu, 2006-11-02 at 12:47 -0500, Chris Shoemaker wrote: On Thu, Nov 02, 2006 at 12:25:17PM -0500, Phil Longstaff wrote: On Thu, 2006-02-11 at 08:40 -0600, Daniel Espinosa wrote: 2006/11/1, Derek Atkins [EMAIL PROTECTED]: Quoting Daniel Espinosa [EMAIL PROTECTED]: Also, we'll need to make changes to handle the fact that file:// should get redirected to sqlite:// -- but the code will need to test the file first to see what kind of file it is, so that File - Open does the right thing. I.e., the fact that we're using SQLite should get hidden from the user when we migrate to it. I think the URI mus be gda:// or db://, think that gda is wrapper for many DB backends not just sqlite. At some level we need to be able to specify what kind of database is sitting behind there. At SOME point we need to know how to specify a filename for SQLite vs. a host/port/user/password for PG. So clearly there's some differentiation there. Isn't the case for GDA, when you create a DSN, you can use this name to connect: you just need to specify the DSN, user, password and some options (read only for example) see the libgda.h file where you'll find some convenient functions to easy use GDA and quick do some very common task. But this is irrelevant to what I meant. What the user types into the File-Open dialog does not need to be the string that gets passed the GDA. If you have an option to connect or open a DSN the URI could be: gda://gnucash:username:password With a gnomedb-login widget you can select a predefined DNS, get username and password, and thats all you can pass it to the QOF beggin session function to open the back end. I'm just pointing out that we need to intercept that input and handle it appropriately, which may mean adjusting the actual string and perhaps calling the XML or GDA-with-SQLite backends. In the event that GC will use just SQLite or other DB engines, you don't need a special intercept, I think the dialog *must* allways show a gnomedb-login widget to select the DSN, write a user and a password, and Go! I haven't thought through all of the issues around connections, but I don't think we want to use predefined DSNs. A user shouldn't have to set up the GC DSN with an external tool in order to use that DSN within gnucash. Phil At least for an initial implementation, I recommend letting the external tools handle DSN setup. The most general setups (i.e. anything other than sqllite) will probably require external configuration anyway. Once it's working, we can worry about streamlining setup for the simple cases. -chris ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: GC, QOF and queries
On Thu, 2006-02-11 at 16:53 -0500, Chris Shoemaker wrote: On Thu, Nov 02, 2006 at 08:47:30AM -0500, Phil Longstaff wrote: I have started working on a gda backend and am starting with a QofQuery - SQL translator. Have you looked at just directly using the GdaQuery objects? You can constuct an abstract query out of GdaQueryFieldFields, GdaQueryFieldValues and such. Then, libgda will emit the provider-specific SQL for that query. I hadn't yet. I had an older version of libgda which didn't have GdaQuery. I've downloaded the latest version and am looking at it. To be frank, IMO, GdaQuery is a better data model for queries than QofQuery. By better, I mean more appropriate for GnuCash. I think it's very unfortunate that GnuCash uses its own home-grown object-agnostic query representation. Someone else will probably disagree. They do seem to have similar functionality. It would be interesting if GdaQuery were used and the current file backend acted like an in-memory DBMS. But, if you re-parented GnuCash's engine objects with a GnuCash-sepcific GncObject (even with GValue parameters, maybe), and implemented the QofQuery functionality by generating a GdaQuery, you would be my hero. But that's probably more work than you were hoping for. *sigh* Anyway, try to avoid writing the SQL emitter, if you can. I don't really want to gut the core of GC and rebuild it around Gda. Phil ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: GC, QOF and queries
Quoting Phil Longstaff [EMAIL PROTECTED]: On Thu, 2006-02-11 at 16:53 -0500, Chris Shoemaker wrote: On Thu, Nov 02, 2006 at 08:47:30AM -0500, Phil Longstaff wrote: I have started working on a gda backend and am starting with a QofQuery - SQL translator. Have you looked at just directly using the GdaQuery objects? You can constuct an abstract query out of GdaQueryFieldFields, GdaQueryFieldValues and such. Then, libgda will emit the provider-specific SQL for that query. I hadn't yet. I had an older version of libgda which didn't have GdaQuery. I've downloaded the latest version and am looking at it. What version of LibGDA do you need to get GdaQuery? Is libgda-1.9.100 recent enough? Or do you need something more recent than that? (I ask because 1.9.100 is what FC5 has). Anyway, try to avoid writing the SQL emitter, if you can. I don't really want to gut the core of GC and rebuild it around Gda. Probably a good idea... Phil -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH [EMAIL PROTECTED]PGP key available ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: GC, QOF and queries
On Thu, 2006-11-02 at 21:27 -0500, Phil Longstaff wrote: On Thu, 2006-02-11 at 16:53 -0500, Chris Shoemaker wrote: Anyway, try to avoid writing the SQL emitter, if you can. I don't really want to gut the core of GC and rebuild it around Gda. I've been thinking of gutting the core of GC and rewriting everything based on GObjects. :-) David ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: GC, QOF and queries
On Thu, 2006-02-11 at 22:04 -0500, Derek Atkins wrote: Quoting Phil Longstaff [EMAIL PROTECTED]: On Thu, 2006-02-11 at 16:53 -0500, Chris Shoemaker wrote: On Thu, Nov 02, 2006 at 08:47:30AM -0500, Phil Longstaff wrote: I have started working on a gda backend and am starting with a QofQuery - SQL translator. Have you looked at just directly using the GdaQuery objects? You can constuct an abstract query out of GdaQueryFieldFields, GdaQueryFieldValues and such. Then, libgda will emit the provider-specific SQL for that query. I hadn't yet. I had an older version of libgda which didn't have GdaQuery. I've downloaded the latest version and am looking at it. What version of LibGDA do you need to get GdaQuery? Is libgda-1.9.100 recent enough? Or do you need something more recent than that? (I ask because 1.9.100 is what FC5 has). I don't know. On the www.gnome-db.org web site, the 1.9.102.changes file is the first one I can see that mentions GdaQuery. That, of course, doesn't mean it doesn't exist earlier. Phil ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Compiling GnuCash on Windows
Andreas Köhler wrote: Hi, Ivars Grinbergs wrote: Andreas Köhler wrote: You have to admit that this stack trace is not extraordinary useful ;-) But yesterday I managed to improve, maybe you can try to do the same? Here is what I did: * download and unpack `pd' and `MMP' from http://www.trapkit.de, you will need the Microsoft .NET Framework Version 2.0 to run the latter * make gnucash crash within gdb * determine the PID of the running gnucash-bin process (Ctrl+Alt+Del) * open a shell and enter `pd -p $pid my.dump', where $pid is your pid * open mmp, open my.dump, let it parse it (click away errors you get, ignore please wait dialogs that do not go away and also crashes when you try to close mmp after your work) * see frame #4, it says 0x0077a51c... try to find the dll that got mapped there and also its base address (one of the first columns) * enter `add-symbol-file $mydll $myaddr' into gdb, where $mydll might be libgncmod-gnome-utils-0.dll or such, and myaddr the base address mmp told you; confirm with y * bt again Success? hopefully :) here is what I have got: [snip] sorry for the answer in a hurry. Can you please double-check that 1) you select the one line in mappings within mmp such that mapping_start = 0x0077a51c mapping_end 2) $mydll is the basename (the part after the last backslash) in the mapped_from column 3) $myaddr is the mapping_start? So yes, the backtrace looks better, but still lacks real debugging information (function names, line numbers). I expect you did not change install.sh so that it either does not include debug symbols or strips the binaries... Go go, well done so far! -- andi5 here is new results with fresh compiled stuff (This copy was built from svn r15078 on 2006-11-03.) Actions-Scheduled Transactions-Scheduled Transaction Editor (gdb) bt #0 0x6b072b01 in _libmsvcrt_a_iname () #1 0x673116f0 in _libmsvcrt_a_iname () #2 0x6b073034 in _libmsvcrt_a_iname () #3 0x6b046dd4 in __RUNTIME_PSEUDO_RELOC_LIST__ () #4 0x0063a3dc in gnc_druid_gnome_get_type () at gnc-druid-gnome.c:40 #5 0x6275c9f4 in _libws2_32_a_iname () #6 0x627466f7 in _libws2_32_a_iname () #7 0x62745b39 in _libws2_32_a_iname () #8 0x627465eb in _libws2_32_a_iname () #9 0x627466d6 in _libws2_32_a_iname () #10 0x00637ec0 in gnc_dense_cal_draw_to_buffer (dcal=0x7c90ee18) at gnc-dense-cal.c:1275 #11 0x63054ab6 in gnc_ui_scheduled_xaction_dialog_create () at dialog-scheduledxaction.c:1250 #12 0x62743935 in _libws2_32_a_iname () #13 0x62756f35 in _libws2_32_a_iname () #14 0x62757cde in _libws2_32_a_iname () #15 0x62757f56 in _libws2_32_a_iname () #16 0x6048b824 in _libmsvcrt_a_iname () #17 0x62743935 in _libws2_32_a_iname () #18 0x62756f35 in _libws2_32_a_iname () #19 0x62757cde in _libws2_32_a_iname () #20 0x62757f56 in _libws2_32_a_iname () #21 0x606999e5 in _libmsvcrt_a_iname () #22 0x6058acec in _libmsvcrt_a_iname () #23 0x6058aff5 in _libmsvcrt_a_iname () #24 0x605774a2 in _libmsvcrt_a_iname () #25 0x62743935 in _libws2_32_a_iname () #26 0x62756b66 in _libws2_32_a_iname () #27 0x62757a3c in _libws2_32_a_iname () #28 0x62757f56 in _libws2_32_a_iname () #29 0x60699b74 in _libmsvcrt_a_iname () #30 0x60574651 in _libmsvcrt_a_iname () #31 0x6057593d in _libmsvcrt_a_iname () #32 0x6b07098e in _libmsvcrt_a_iname () #33 0x672dd8f7 in _libmsvcrt_a_iname () #34 0x672dedcb in _libmsvcrt_a_iname () #35 0x672defaa in _libmsvcrt_a_iname () #36 0x60574eae in _libmsvcrt_a_iname () #37 0x006448d2 in set_chart_axis_labels_from_hash (chart=0x22e9f0, eb=0x0) at gnc-html-graph-gog.c:269 #38 0x00401746 in inner_main (closure=0x0, argc=1, argv=0xbd6ea8) at gnucash-bin.c:493 #39 0x65e2564d in scm_boot_guile (argc=1, argv=0xbd6ea8, main_func=0x401600 inner_main, closure=0x0) at init.c:635 #40 0x00401e26 in main (argc=1, argv=0xbd6ea8) at gnucash-bin.c:549 (gdb) wbr, ivars ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
