Re: Building on Windows from scratch - difftime problem found ( was datediff )
On 27/01/2014 17:20, John Ralls wrote: On Jan 27, 2014, at 8:29 AM, Derek Atkins warl...@mit.edu wrote: Gary Bilkus m...@gary.bilkus.com writes: Given that time_t is always a signed integer value, wouldn't return (double)(time1-time2) just work anyway, at least as far as a patch for mingw is concerned? Is it always a signed integer? Can't it sometimes be unsigned? This is the year 2037 problem, where 32-bit unsigned time rolls over. However there is also a Year 2106 problem, which is where 32-bit unsigned time rolls over. I think there *are* some systems where it's unsigned, but still 32 bits. Or at least there are apps where that is the case. It's actually the 2038 problem, as a signed 32-bit time_t overflows at 03:14:07 2038-01-19. Representation of time_t is up to the C library unless the application re-implements all of the standard C functions which use it including retrieving the tick count from the system clock. http://en.wikipedia.org/wiki/Unix_time#Representing_the_number reports that QNX V6 implements it as unsigned, but that it's generally implemented as signed. I don't think there's any reason to port GC to QNX. None of which matters a whole lot. We needed dates past 2038 to support scheduled transactions, so we don't use time_t. AQBanking and LibOFX aren't AFAICT concerned about far-future dates, so for the moment time_t, even 32 bit, is fine. The real problem we're dealing with here is that MinGW screwed up handling Microsoft's time_t size arrangements, effectively breaking it for 64-bit values. Until they sort that out, ISTM the solution is to coerce 32-bit time_t on 64-bit builds. Regards, John Ralls The answer to the 'is it always a signed integer' question is: yes, on mingw it is, and since we're discussing a patch for the windows port, does it matter if there are any really weird unix variants which use unsigned ( and I do mean weird ). The problem with the simple code I proposed above is the edge case caused if time1 is very large and positive, and time2 is very large and negative, meaning the result would overflow even a 64 bit int before being coerced to double. But that isn't going to happen with any plausible use case for these libraries ( the only time ofx uses the function is in a minor correction of a few hours to the date based on some timezone subtleties as far as I can tell ). If I were writing a library for use by the entire world, I'd care that time_t might be unsigned on some variant. Since I'm just trying to find a patch which allows gnucash to compile on Windows, and should never be applied elsewhere, I don't care if time_t is sometimes unsigned on unix boxes. But I don't own the project, so I'm still looking for a definitive understanding of what is likely to be acceptable as a patch which eventually gets into the official repository. It's not urgent for me, because I have what I need now, which is a way of compiling gnucash on windows which works, and I can therefore start to investigate the stuff I wanted to do in the first place! But I'm still happy to help if I get a clear steer. And of course if I hit any further issues, I'll be happy to investigate/report BTW, even on a 64bit machine, the mingw tools as used in geert's scripts produce 32bit executables. However, the only way to produce an executable which will work on all the supported windows OSs seems to be to compile on an XP box as otherwise it fails on XP with various complaints about missing libraries. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Building on Windows from scratch - difftime problem found ( was datediff )
On 24/01/2014 17:08, Derek Atkins wrote: John Ralls jra...@ceridwen.us writes: if (sizeof(time_t) == 8) return (double)((int64)time1 - (int64)time2); else return (double)((int32)time1 - (int32)time2); This code probably wouldn't compile cleanly. It would complain about casting to different sizes. Even though theoretically the compiler should be able to optimize the branch by noticing that it is always true or always false, it will still complain about the unused branch. (I know this from personal experience). That could be done as a macro and inserted into one of the header files in each library. Regards, John Ralls -derek Given that time_t is always a signed integer value, wouldn't return (double)(time1-time2) just work anyway, at least as far as a patch for mingw is concerned? ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Building on Windows from scratch - datediff problem found
On 23/01/2014 22:47, John Ralls wrote: On Jan 23, 2014, at 7:23 AM, Gary Bilkus m...@gary.bilkus.com wrote: I've done some more testing and found a problem with libofx and possibly aqbanking ( which I don't use ). It's easy enough to work round, but I'm not sure what the correct fix should be on Windows The problem is that there's a known issue with datediff and mingw, due to differences in the versions of MSCVRT used by mingw as to whether they expect time_t to be 32 or 64 bits. If you know you are compiling for Windows 7, you can get it to work by explicitly setting the windows version appropriately, so that it will use the 64 bit versions of time_t ( even on 32 bit windows ). However, I suspect that compiling that way won't work on XP which doesn't have the 64 bit version. There is lots of noise about this issue in various forums, but no clear answer what the 'correct' solution is if you want to be able to compile on any supported Windows version, and ideally get a package which works everywhere as well. Anyone have any good ideas how to fix this cleanly. The least bad solution might be simply to replace datediff with a simple subtraction, which should work for the cases it's used in libofx. But other dependencies might be different. Are you perhaps thinking of “difftime”? DATEDIFF is a SQL function; difftime is a standard C Library function. This bug seems to be what you’re talking about: http://sourceforge.net/p/mingw/bugs/2152/, linked from http://mingw.5.n7.nabble.com/difftime-broken-td33080.html. So Microsoft has invented a new twist on the 32-bit vs. 64-bit time_t problem by having both and a rather graceless way of determining which to use. In GnuCash we finessed that by not using the standard C functions because we need 64-bit time_t regardless of whether the platform provides it. We’re currently using Glib functions that don’t use it; soon we’ll switch to Boost functions that don’t use it either. It looks to from the bug that you have it backwards: You need to coerce 32-bit time_t because MinGW is screwed up and only calls difftime32() regardless of the size of time_t. That means that you can’t build GnuCash with MinGW wsl=4.0 on a Win64 system until they fix the bug, or unless AQBanking and LibOFX work around the bug by replacing difftime with a subtraction-and-cast. Regards, John Ralls Sorry, yes, it is of course difftime I meant. I suppose I have it backwards if you mean that I want to use 64 bits but the latest mingw insists on 32 bits. In fact, it will call difftime64 if you define _WIN32_WINNT to _WIN32_WINNT_WIN7 inside _mingw.h . But while that proves the diagnosis, it clearly isn't the right patch! This is not just a 'build on 64 bits' problem by the way. The problem exists even on 32 bit Windows XP using a VM I created to test on, although what's going wrong under the hood may be subtly different, and the WIN32_WINNT_WIN7 kludge obviously doesn't work! . So it's worth fixing if the aim is to have a 'just works' build of gnucash for Windows on mingw. The safest fix is probably to define a 'sufficiently good' difftime and patch both libofx and aqbanking with that version as part of the install.sh process. But before I do that, I'd like to know that the gnucash maintainers would accept it, and if not, what alternative would be OK for eventual inclusion in geerts update. Gary ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Building on Windows from scratch - datediff problem found
I've done some more testing and found a problem with libofx and possibly aqbanking ( which I don't use ). It's easy enough to work round, but I'm not sure what the correct fix should be on Windows The problem is that there's a known issue with datediff and mingw, due to differences in the versions of MSCVRT used by mingw as to whether they expect time_t to be 32 or 64 bits. If you know you are compiling for Windows 7, you can get it to work by explicitly setting the windows version appropriately, so that it will use the 64 bit versions of time_t ( even on 32 bit windows ). However, I suspect that compiling that way won't work on XP which doesn't have the 64 bit version. There is lots of noise about this issue in various forums, but no clear answer what the 'correct' solution is if you want to be able to compile on any supported Windows version, and ideally get a package which works everywhere as well. Anyone have any good ideas how to fix this cleanly. The least bad solution might be simply to replace datediff with a simple subtraction, which should work for the cases it's used in libofx. But other dependencies might be different. Gary ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Building on Windows from scratch - guile problem SOLVED
On 18/01/2014 09:53, Geert Janssens wrote: On Friday 17 January 2014 07:30:00 John Ralls wrote: OK Geert, I think I have what you want at http://www.greenwheel.com/publicFiles/rebase-patches.zip Let me know if this works for you. Not being a git expert, it's possible I've not quite done the right thing, but I think this should be OK. As another option, perhaps the most git-ish (sorry) of all, would be for Gary to get a (free) Github account, fork Geert's repo, make his branch, push that back to *his* repo, and then from Github send Geert a pull request. I know I've argued against allowing this in the past, but I'm coming around to the idea that we need to make it easier for folks to offer patches. Heh, I didn't want to propose this exactly because of your opposition in the past. But I have been thinking of leveraging github's pull requests as well. I see for example that swig is using this approach rather succesfully. I can imagine that a project the size of a linux kernel needs some stricter rules to keep organized. But GnuCash is pretty small in comparison. Reminds me we still have to discuss our future branching strategy, but that's for another thread. Back to the patches at hand: Gary, I tried to download the zip file you made available, but I get a permission error on that website. Can you check that ? Geert Sorry Geert, forgot to add read perms to the file. Should be OK now. Gary ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Building on Windows from scratch - guile problem SOLVED
On 16/01/2014 15:38, Geert Janssens wrote: On Thursday 16 January 2014 15:06:55 Gary Bilkus wrote: On 16/01/2014 13:26, Geert Janssens wrote: Gary, While looking at your changes I noticed you changed two lines in the vbs script. One is that you added my repository/branch in a comment. That's ok and makes it easier for others to start. The second is to install msys-patch. Is there a reason you do this in the vbs script and not in install-impl.sh ? Geert Hi Geert. The reason I added in msys-patch to my version of your script is so that the instructions I posted on the wiki would work, since they tell you to run your vbs script and then run patch against the 2.6 repo with my patchfile, and that doesn't work if you don't yet have patch installed. Of course, as and when there's a git repo with the patches already incorporated, that step is no longer needed and nor is patch. But it doesn't do much harm to leave it around, and would make it easier for people who have to play catch-up the next time a downstream dependency gets broken. Gary Hi Gary, That makes sense. The reason I'm very cautious about adding stuff in the bootstrap script is that mingw-get is fairly fragile. The bootstrap script unconditionally installs the most recent version of the various packages, but in the install.sh script we force specific versions. If at some point the most recent version is more recent than what we explicitly set this will probably cause mingw-get to error out. That may or may not be bad but at least pretty confusing to new users. We may fix this by installing very specific versions in the bootstrap script already instead of the latest available. Although that approach risks that these versions will at some point get out of sync with the versions defined in defaults.sh. But IMO that is less of an issue. If this happens the installation script will update the packages to the proper versions without errors the first time it runs. I'll admit this is close to nitpicking. There are bigger issues to solve right now, but I mention it because now I noticed it. I will probably forget later on. Geert I completely understand the thinking. That said, I think patch is probably a pretty safe program to just download, given its longevity and stability at this point, compared to things like say the c compiler! ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Building on Windows from scratch - guile problem SOLVED
On 16/01/2014 13:23, Geert Janssens wrote: On Thursday 16 January 2014 12:14:49 Gary Bilkus wrote: So just to make sure I understand exactly what you need. 1. I should get the gnucash.git repository from git://github.com:gjanssens/gnucash.git 2. I should git branch -t mingw origin/mingw-rebasing and check out that branch 3. I should appy my patches to that branch - ignoring any which are already there 4. I should run git diff to get a series of patches against the branch in the repository 5. I should split the resulting diff into different files relating to the different fixes 6. I should post the result somewhere and tell you where it is Gary Gary, That's close. But git's workflow is slightly different: 1 and 2 are correct 3. Apply your patches and ignore those that are already there is also correct. Then before committing anything it's worth considering which changes logically belong together and check these changes in in separate commits. 'git add -i' will be tremendously helpful for this part (adding changes into the index interactively). 4. Each time you have added a coherent set of changes to the index file, you can create a (local) commit using 'git commit'. You may want to use clear commit messages in this step as they will eventually end up in the master repository. You can look at my commits for examples but they're only that not hard rules. I suggest though that you explicitly add an author line in your commit message. Since we're still linked to the svn repo, git's author information gets lost for non-committers when we commit to the master repository. This line is in the form: Author: name email 5. When there are no more changes to commit, you can run 'git format-patch' to generate a series of patch files like so: git format-patch origin/mingw-rebasing That should generate the patch files in the current working directory. 6. The normal way to make these patches available to me is to create an enhancement request in bugzilla and attach the patches there. But in this case I'm equally fine if you post them to the list or tell me where you stored them on your own server or whatever. Geert OK Geert, I think I have what you want at http://www.greenwheel.com/publicFiles/rebase-patches.zip Let me know if this works for you. Not being a git expert, it's possible I've not quite done the right thing, but I think this should be OK. Gary ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Building on Windows from scratch - guile problem SOLVED
On 16/01/2014 11:43, Geert Janssens wrote: On Thursday 16 January 2014 11:10:30 Geert Janssens wrote: Gary, Thanks for all your updates. Today I found some time to check which of your fixes I should still add to my windows branch, but got lost in your patch. It looks like you are generating a patch to be applied to the current trunk branch, including all the separate commits from my branch. Unfortunately that makes it hard if not impossible to see only the changes needed on my branch. It's not the intention to apply such a large patch one day to current trunk. Instead my branch will be merged in eventually (likely after the 2.6 branch is generated and certainly not before the dist part and build server scripts are also fixed). So can you extract only the changes that still need to be applied to my branch please ? Ideally split up in small patches per topic (fix -no-undefined, fix guile's str_ncase_comp, ...). That way we generate clean and readable history in the repository. You may want to set up your own clone of the git repository [1] as git can be very helpful in generating such patches. Thanks, Geert [1] http://wiki.gnucash.org/wiki/Git#Non-Committers Also note that I have rebased the mingw-rebasing branch again in my repository to pick up the most recent version of aqbanking and gwenview. I haven't had the opportunity yet to check if these versions build in the new mingw environment. Geert ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel So just to make sure I understand exactly what you need. 1. I should get the gnucash.git repository from git://github.com:gjanssens/gnucash.git 2. I should git branch -t mingw origin/mingw-rebasing and check out that branch 3. I should appy my patches to that branch - ignoring any which are already there 4. I should run git diff to get a series of patches against the branch in the repository 5. I should split the resulting diff into different files relating to the different fixes 6. I should post the result somewhere and tell you where it is Gary ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Building on Windows from scratch - guile problem SOLVED
On 16/01/2014 13:26, Geert Janssens wrote: Gary, While looking at your changes I noticed you changed two lines in the vbs script. One is that you added my repository/branch in a comment. That's ok and makes it easier for others to start. The second is to install msys-patch. Is there a reason you do this in the vbs script and not in install-impl.sh ? Geert Hi Geert. The reason I added in msys-patch to my version of your script is so that the instructions I posted on the wiki would work, since they tell you to run your vbs script and then run patch against the 2.6 repo with my patchfile, and that doesn't work if you don't yet have patch installed. Of course, as and when there's a git repo with the patches already incorporated, that step is no longer needed and nor is patch. But it doesn't do much harm to leave it around, and would make it easier for people who have to play catch-up the next time a downstream dependency gets broken. Gary ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Building on Windows from scratch - guile problem SOLVED
On 10/01/2014 15:03, John Ralls wrote: On Jan 9, 2014, at 11:13 PM, Gary Bilkus m...@gary.bilkus.com wrote: Well, interestingly enough, the problem is not directly with the compiler optimizer. It's with the configure test for strncasecmp. This test fails on mingw in its current incarnation because guile uses a standard test for the function, but on mingw strncasecmp is actually a cpp definition. As a result, guile is compiled with #HAVE_STRNCASECMP unset, and so guile tries to create its own version in read.c Now if you compile with no optimization, the compiler notices that read.c is attempting to create this with a different signature and bombs out. However, with optimisation on, the code compiles for some reason, and then fails to run properly. So there seem to be two problems: one in configure for guile and/or the standard configure macros on mingw, the other in the compiler. Fortunately, there's a very easy although ugly workaround, which is to add an echo #define HAVE_STRNCASECMP config.h Would adding -DHAVE_STRNCASECMP to $CFLAGS work? It's a bit cleaner than echoing a #define into the config header. Better yet, sometimes there's a variable that can be defined on the configure command line -- perhaps $ac_have_strncasecmp -- to force configure to do the right thing. in install-impl.sh just after the guile configure and before the make I've incorporated this fix into my downloadable file of fixes as referred to on the wiki page I updated. More as and when I find any further issues. As always, feedback or other experiences welcome. Regards, John Ralls I agree that the configure commandline change would be cleaner, and if I can find out what to do I'll change my fix. I disagree that a CFLAGS define is cleaner. With my solution the define is in the right file, even if it gets there for the wrong reason. That way, it guarantees not to affect any compilation which doesn't involve including config.h, which saves having to check for any unexpected consequenses elsewhere. Gary ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Building on Windows from scratch - guile problem
I have done some testing of my build, and it appears there is some kind of problem with guile The symptom is that whenever I try to run a report, even hello world, it fails. Digging into things, it turns out that there is at least one problem with the guile build, whcih is that character constants like #\space are not being initialized correctly. Just running guile standalone shows the problem. guile #\space \#nul So there's obviously some problem with the guile build over and above the library naming one I found earlier. Not sure if it's the version, the compiler version or what. Will investigate further, but any suggestions or experience from other would be welcome Gary On 08/01/2014 15:07, Gary Bilkus wrote: I have written up the procedure which as of today is working to build gnucash 2.6 from scratch on windows and updated http://wiki.gnucash.org/wiki/Windows/Development It would be really nice if the patch file I have created along with my modified version of geert's vbs file could find their way into the official repo. It should be safe enough as all the changes are to the win32 directory except for two, which I'm reasonably confident won't break anything else: - configure.ac now deals with the -no-undefined flag more cleverly - gnc-split-reg.h has a couple of #undef statements added to avoid DELETE and DUPLICATE being defined in windows headers. It probably also makes sense for the page to be split up again, and some of the older information moved away, but it would be good to get some feedback from people who try following the instructions. I've done my best to ensure that there are no ambiguities or misprints, and the entire process has worked for me, but feel free to fix any errors, or tell me of any changes I can/should make to the zip file I've published. Please note that I haven't extensively tested all the features of the program. There could be some issues with the build which don't immediately manifest themselves..but at least it runs. Also, I haven't yet tried packaging the app into an msi or installable exe Gary ___ 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: Building on Windows from scratch - guile problem
Hmm, The problem appears to be with the compiler optimiser doing something too aggressive, If I manually recompile guile with -O0 instead of -O2 the problem seems to go away. This could be caused by one of the new optimisations in the more recent versions of gcc in which case it could start to matter on *nix at some point. Anyone know much about this? Gary -Original message- From:Gary Bilkus m...@gary.bilkus.com Sent:Thu 09-01-2014 13:37 Subject:Building on Windows from scratch - guile problem To:gnucash-devel@gnucash.org; I have done some testing of my build, and it appears there is some kind of problem with guile The symptom is that whenever I try to run a report, even hello world, it fails. Digging into things, it turns out that there is at least one problem with the guile build, whcih is that character constants like #\space are not being initialized correctly. Just running guile standalone shows the problem. guile #\space \#nul So there's obviously some problem with the guile build over and above the library naming one I found earlier. Not sure if it's the version, the compiler version or what. Will investigate further, but any suggestions or experience from other would be welcome Gary On 08/01/2014 15:07, Gary Bilkus wrote: I have written up the procedure which as of today is working to build gnucash 2.6 from scratch on windows and updated http://wiki.gnucash.org/wiki/Windows/Development It would be really nice if the patch file I have created along with my modified version of geert's vbs file could find their way into the official repo. It should be safe enough as all the changes are to the win32 directory except for two, which I'm reasonably confident won't break anything else: - configure.ac now deals with the -no-undefined flag more cleverly - gnc-split-reg.h has a couple of #undef statements added to avoid DELETE and DUPLICATE being defined in windows headers. It probably also makes sense for the page to be split up again, and some of the older information moved away, but it would be good to get some feedback from people who try following the instructions. I've done my best to ensure that there are no ambiguities or misprints, and the entire process has worked for me, but feel free to fix any errors, or tell me of any changes I can/should make to the zip file I've published. Please note that I haven't extensively tested all the features of the program. There could be some issues with the build which don't immediately manifest themselves..but at least it runs. Also, I haven't yet tried packaging the app into an msi or installable exe Gary ___ 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 ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Building on Windows from scratch - SUCCESS
I have written up the procedure which as of today is working to build gnucash 2.6 from scratch on windows and updated http://wiki.gnucash.org/wiki/Windows/Development It would be really nice if the patch file I have created along with my modified version of geert's vbs file could find their way into the official repo. It should be safe enough as all the changes are to the win32 directory except for two, which I'm reasonably confident won't break anything else: - configure.ac now deals with the -no-undefined flag more cleverly - gnc-split-reg.h has a couple of #undef statements added to avoid DELETE and DUPLICATE being defined in windows headers. It probably also makes sense for the page to be split up again, and some of the older information moved away, but it would be good to get some feedback from people who try following the instructions. I've done my best to ensure that there are no ambiguities or misprints, and the entire process has worked for me, but feel free to fix any errors, or tell me of any changes I can/should make to the zip file I've published. Please note that I haven't extensively tested all the features of the program. There could be some issues with the build which don't immediately manifest themselves..but at least it runs. Also, I haven't yet tried packaging the app into an msi or installable exe Gary ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Building on Windows from scratch
On 28/12/2013 08:16, Gary Bilkus wrote: Thanks Geert, I've got a bit furtherthe program now starts and then dies after showing a splash screen. I found a gnucash-launcher.cmd script which didn't quite work, because it was missing references to libxslt enchant and libsoup If I add those ( bin and lib ) to the path, the program no longer complains, but dies almost immediately. If I run inside gdb, it seems to be failing somewhere in guile initialization which causes the program to exit. I've also set up an XP VM and run on there under 32 bits, just to see what happens. Same thing - it will compile OK, and dies at the same point. My next stage will be to recompile guile and leave the tmp directory around, so that gdb has source to work from, and see if a detailed debug session shows up the problem. Unless you have a better idea! Gary I've made some more progress on my attempts to compile gnucash on Windows from scratch. Firstly, I've tried running everything on a 32 bit VM, and there's no real difference. Some of the compiler warnings go away, but the other problems remain. So I did some debugging, and discovered that the first reason gnucash bombs out is that the guile dll names for libguile-srfi-srfi... in guile/bin are inconsistent with the names of the files being loaded by the corresponding scm file. I think this is because the versioning of libraries under unix assumes that the minor version is linked to the major version, but that hasn't happened under windows. So I copied, for example libguile-srfi-srfi-1-v-3-3.dll to libguile-srfi-srfi-1-v-3-3.dll which seems to have fixed that problem. I now get some debug output in the gnucash.trace...log files saying ...Could not locate module gnucash/app-utils interface v.0 register/ledger-core ...register/register-gnome... for loads of the modules gnucash loads on start. So it bombs out there. When I have a look in the guile-modules directory, I can see some of these, but nothing in the register subdirectory for example. Any ideas? It seems so close now. BTW, I've also tried building the newly released 2.6.0. It behaves identically up to this point, so from now on I will concentrate on trying to build 2.6 after first running Geerts install processes to create the necessary environment Gary ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Building on Windows from scratch
On 07/01/2014 13:52, Gary Bilkus wrote: On 28/12/2013 08:16, Gary Bilkus wrote: Thanks Geert, I've got a bit furtherthe program now starts and then dies after showing a splash screen. I found a gnucash-launcher.cmd script which didn't quite work, because it was missing references to libxslt enchant and libsoup If I add those ( bin and lib ) to the path, the program no longer complains, but dies almost immediately. If I run inside gdb, it seems to be failing somewhere in guile initialization which causes the program to exit. I've also set up an XP VM and run on there under 32 bits, just to see what happens. Same thing - it will compile OK, and dies at the same point. My next stage will be to recompile guile and leave the tmp directory around, so that gdb has source to work from, and see if a detailed debug session shows up the problem. Unless you have a better idea! Gary I've made some more progress on my attempts to compile gnucash on Windows from scratch. Firstly, I've tried running everything on a 32 bit VM, and there's no real difference. Some of the compiler warnings go away, but the other problems remain. So I did some debugging, and discovered that the first reason gnucash bombs out is that the guile dll names for libguile-srfi-srfi... in guile/bin are inconsistent with the names of the files being loaded by the corresponding scm file. I think this is because the versioning of libraries under unix assumes that the minor version is linked to the major version, but that hasn't happened under windows. So I copied, for example libguile-srfi-srfi-1-v-3-3.dll to libguile-srfi-srfi-1-v-3-3.dll which seems to have fixed that problem. I now get some debug output in the gnucash.trace...log files saying ...Could not locate module gnucash/app-utils interface v.0 register/ledger-core ...register/register-gnome... for loads of the modules gnucash loads on start. So it bombs out there. When I have a look in the guile-modules directory, I can see some of these, but nothing in the register subdirectory for example. Any ideas? It seems so close now. BTW, I've also tried building the newly released 2.6.0. It behaves identically up to this point, so from now on I will concentrate on trying to build 2.6 after first running Geerts install processes to create the necessary environment Gary UPDATE..The problem with the modules appears to be a slight red-herring to do with having 2.6 around.If I build what seems to be 2.5.something based on the git repository from geert, with all the changes I've mentioned, I can now get gnucash to compile and run ( at least as far as letting me see an account list - i haven't tested further ).However, if I try to build 2.6 from the distributed source, I get the module location problems above and it bombs out. For some reason, the 2.5 version seems to take ages ( almost a minute ) to load the qif guile module. I shall run some tests to confirm the program is really working and let people know. It would obviously be useful to capture what I've learned in a more structured way than having people read the entire thread. Should I update the wiki article on building from Windows? Can I safely point that article to geerts repository at least for the time being? Gary ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Building on Windows from scratch
On 07/01/2014 18:16, Derek Atkins wrote: Gary Bilkus m...@gary.bilkus.com writes: UPDATE..The problem with the modules appears to be a slight red-herring to do with having 2.6 around.If I build what seems to be 2.5.something based on the git repository from geert, with all the changes I've mentioned, I can now get gnucash to compile and run ( at least as far as letting me see an account list - i haven't tested further ).However, if I try to build 2.6 from the distributed source, I get the module location problems above and it bombs out. It does not surprise me at all that you cannot build on Windows from the tarball. What if you use the 2.6 (trunk) git branch? For some reason, the 2.5 version seems to take ages ( almost a minute ) to load the qif guile module. I shall run some tests to confirm the program is really working and let people know. It would obviously be useful to capture what I've learned in a more structured way than having people read the entire thread. Should I update the wiki article on building from Windows? Can I safely point that article to geerts repository at least for the time being? Please do. Gary -derek Actually, by starting again from scratch and being really careful, I have managed to build 2.6.0 as distributed and got it working. I will write up exactly what I did on the wiki and notify the group when I've finished. Hopefully, the various changes to the contents of packaging/win32 which are needed to make build.sh work with the current versions of the third-party software can be incorporated into the source. Thanks to everyone, and Geert in particular, for the help I needed. Gary ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Building on Windows from scratch
Nice you got it to compile ! With my local modifications I got stuck in engine/test with this error: /bin/sh ../../../libtool --tag=CC --mode=link gcc -I. -I/c/soft/gnucash.git/src/engine/test -I../../.. - I/c/soft/gnucash.git/src/engine/ -DTESTPROG=test_engine -mms-bitfields - Ic:/soft/gnome/include/glib-2.0 -Ic:/soft/gnome/lib/glib-2.0/include -Werror -Wdeclaration-after- statement -g -mms-bitfields -g -Wall -Wunused -Wmissing-prototypes -Wmissing-declarations - Wno-unused -no-undefined -L/c/soft/regex/lib -lregex -L/c/soft/gnome/lib -L/c/soft/guile/lib - L/c/soft/libdbi/lib -L/c/soft/gwenhywfar/lib -L/c/GCDevel/GC-Maint/hh/lib -L/c/soft/sqlite3/lib - L/c/soft/enchant/lib -L/c/soft/libxslt/lib -L/c/soft/mingw/lib -g -o test-engine.exe test_engine-test- engine.o test_engine-utest-Account.o test_engine-utest-Budget.o test_engine-utest-Invoice.o libutest-Split.la libutest-Trans.la ../../../src/libqof/qof/libgnc-qof.la ../../../src/gnc-module/libgnc- module.la ../../../src/test-core/libtest-core.la ../libgncmod-engine.la ../test-core/libgncmod-test- engine.la ../../../src/core-utils/libgnc-core-utils.la -Lc:/soft/gnome/lib -lgio-2.0 -lgobject-2.0 - lgthread-2.0 -lgmodule-2.0 -lglib-2.0 -lintl -lm libtool: link: gcc -I. -I/c/soft/gnucash.git/src/engine/test -I../../.. -I/c/soft/gnucash.git/src/engine/ - DTESTPROG=test_engine -mms-bitfields -Ic:/soft/gnome/include/glib-2.0 - Ic:/soft/gnome/lib/glib-2.0/include -Werror -Wdeclaration-after-statement -g -mms-bitfields -g - Wall -Wunused -Wmissing-prototypes -Wmissing-declarations -Wno-unused -g -o .libs/test- engine.exe test_engine-test-engine.o test_engine-utest-Account.o test_engine-utest-Budget.o test_engine-utest-Invoice.o -L/c/soft/regex/lib -L/c/soft/gnome/lib -L/c/soft/guile/lib - L/c/soft/libdbi/lib -L/c/soft/gwenhywfar/lib -L/c/GCDevel/GC-Maint/hh/lib -L/c/soft/sqlite3/lib - L/c/soft/enchant/lib -L/c/soft/libxslt/lib -L/c/soft/mingw/lib ./.libs/libutest-Split.a - Lc:/soft/gnome/lib -Lc:/soft/guile/lib -L/c/soft/readline/lib ./.libs/libutest-Trans.a /c/soft/gnucash/build/src/test-core/.libs/libtest-core.a ../../../src/libqof/qof/.libs/libgnc-qof.dll.a ../../../src/gnc-module/.libs/libgnc-module.dll.a ../../../src/test-core/.libs/libtest-core.a ../.libs/libgncmod-engine.a ../test-core/.libs/libgncmod-test-engine.a /c/soft/gnucash/build/src/engine/.libs/libgncmod-engine.a /c/soft/gnucash/build/src/gnc- module/.libs/libgnc-module.dll.a /c/soft/gnucash/build/src/core-utils/.libs/libgnc-core-utils.dll.a ../../../src/core-utils/.libs/libgnc-core-utils.dll.a c:/soft/guile/lib/libguile.dll.a -lgmp -lws2_32 /mingw/lib/libltdl.dll.a -lpthread /c/soft/gnucash/build/src/libqof/qof/.libs/libgnc-qof.dll.a -lregex - lgio-2.0 -lgobject-2.0 -lgthread-2.0 -lgmodule-2.0 -lglib-2.0 /mingw/lib/libintl.dll.a /mingw/lib/libiconv.dll.a -pthread -Lc:/soft/gnucash/inst/lib -Lc:/soft/guile/lib -L/mingw/lib ../.libs/libgncmod-engine.a(Transaction.o):Transaction.c:(.data+0x10): multiple definition of `trans_is_closing_str' ./.libs/libutest-Trans.a(utest-Transaction.o):utest-Transaction.c:(.data+0x14): first defined here collect2.exe: error: ld returned 1 exit status The only other source file issue is in gnome-gnc-split-reg.h where we get the error: expected identifier before numeric constant DELETE, A bit of trial and error got this to go away by adding #undef DELETE #undef DUPLICATE on line 116, but to be honest I'm not entirely sure what's going on here yet. After all that, a make followed by make install seems to complete, although with lots of libtool: link: warning : 'c/soft/mongw/lib/lib.la seems to be moved warnings coming up. As Derek already said: this is a normal warning which you can ignore. Unfortunately, after all that, I can't get it to run. If I try to start it from /c/soft/gnucash/inst/bin there are lots of missing dlls, which all appear to be dotted around in other places. If I copy everything into a single directory and try to run I get Error: Unspecified fatal error encountered, aborting. The problem here is that most of the dependencies are not installed in one single location accessible from the Windows path. This installation scheme has been chosen for the lack of a package management system in mingw/Windows. Having each dependency in a separate directory makes it very easy to renew a dependency: simply delete the existing directory and run the build again. There is a way to run gnucash from the install directory though: you have to include all the bin directories of all the dependencies in either the Windows or the MSYS PATH variable. The easiest is write a simple batch script for this. We used to have one, which I deleted at some point (way too early unfortunately). My intention is to restore the ability to run gnucash directly from the installation directory. I'm not sure how though. Instead of requiring a batch file to set up the environment, I'd rather figure out a way to better manage
Re: Building on Windows from scratch
A bit further now. If I change the REL_REPOS_DIR to $GLOBAL_DIR\\gnucash.git This doesn't make sense to me. REL_REPOS_DIR is not used in the install script, but only in the nightly build scripts. Which script are you running exactly to build gnucash ? It should be install.sh then it runs configure OK and bombs out on libxml2 tests This is because the compiler doesn't recognise -no-undefined, so I guess I got to where you were. If you remove -no-undefined from configure.ac and try again, configure completes and the make starts. It then fails in libqof/qof/guid.c line 243 unknown conversion type character l in format [-Werror=format=] and again in line 510 and 513 That's indeed as far as I got before I ran out of time. Geert Hi Geert, I was indeed running install.sh - the version I found in packaging/win32 The reference to REL_REPOS_DIR is actuall in install-impl.sh which is called by install.sh. Specifically, in that file in the function inst_gnucash() around line 1281. Anyway, I've made some more progress. The -no-undefined problem is caused because more recent versions of gcc apparently don't understand that flag, and don't ignore it but just fail. So although you need to pass it to libtool, you mustn't pass it direct to gcc.any more. Unfortunately, that means that adding -no-undefined to LDFLAGS causes lots of the tests in configure to go wrong with compilation errors, and it just happens that the libxml one is the first which is mandatory. I did a very kludgy workaround by removing -no-undefined from configure.ac, running configure, and then running a script to add -no-undefined back into every resulting Makefile. I imagine there's a cleaner fix somewhere to put the flag into libtool only, but I haven't yet found it. Anyway, when you do that, it starts to compile the app, and the next problem is that some of the code files fail to compile. Specifically: libqof/qof/guid.c and backend/xml/sixtp-utils.c both fail with compiler warnings about %llu formats in strings. There appears to be a bug in the version of gcc (4.8.1) as downloaded for mingw cd . which treats these formats as invalid even though they aren't. Then because -Werror is set, the compile fails. The solution for the moment was to edit the Makefile to remove the -Wall from those files. They then recompile happily. The only other source file issue is in gnome-gnc-split-reg.h where we get the error: expected identifier before numeric constant DELETE, A bit of trial and error got this to go away by adding #undef DELETE #undef DUPLICATE on line 116, but to be honest I'm not entirely sure what's going on here yet. After all that, a make followed by make install seems to complete, although with lots of libtool: link: warning : 'c/soft/mongw/lib/lib.la seems to be moved warnings coming up. Unfortunately, after all that, I can't get it to run. If I try to start it from /c/soft/gnucash/inst/bin there are lots of missing dlls, which all appear to be dotted around in other places. If I copy everything into a single directory and try to run I get Error: Unspecified fatal error encountered, aborting. And that's as far as I've got. Gary ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Building on Windows from scratch
I'm sorry I didn't mention this more clearly. The documentation is not updated yet. So the information in the README file is still for the old build process. This is how I think you should proceed (I'm assuming you stick with the default path names): - clear every trace of the previous gnucash build environment from your system, including mingw and msys. - download this file: https://raw.github.com/gjanssens/gnucash/mingw-rebasing/packaging/win32/bootstrap_win_dev.vbs This comes from my git repository, but you don't need to have git installed on your system just yet. The top of the file gives a bit more information on what it will do (install minimal mingw, msys, git and clone the gnucash repository). - *intermediate step* edit the file and change the repos url in line 44 to: REPOS_URL = git://github.com:gjanssens/gnucash.git This is only necessary because my work is not in the default gnucash repository yet. - save the file - double-click to execute the file. It will open a console window in which you can follow its progress. Wait until it finishes. - at this point, you should have a new directory c:\soft with at least directories mingw and gnucash.git. Perhaps also a git-1.7.10 directory if git was not yet installed on your system (or maybe even in that case). - *intermediate steps* (no longer necessary when my work is integrated in the main gnucash git repository) * open a git bash window on the newly downloaded repository you can do this via a windows explorer and then right-click on the directory of the repository * track and checkout my mingw branch git branch -t mingw origin/mingw-rebasing git checkout mingw - now open an msys console. The bootstrap script currently doesn't create a softlink on the desktop yet, so you will have to navigate to c:\soft\mingw\msys\1.0\ and double-click msys.bat in there. - within that console, start the gnucash build: * cd /c/soft/gnucash.git/packaging/win32 * ./install.sh With the current state of the branch this should work until the gnucash build step. There I run into no-undefined warnings I haven't had time to figure out yet. Can you try these steps and let me know how it goes ? By the way I'm open to patches to either the build, the README file or other improvements on this subject :) Geert Thanks Geert. I've tried as you suggested. There's one typo above I think REPOS_URL = git://github.com:gjanssens/gnucash.git didn't work for me, but git://github.com/gjanssens/gnucash.git did. The everything seems to go fine until I get: ### isocodes --2013-12-23 19:48:02-- http://pkg-isocodes.alioth.debian.org/downloads/iso-cod es-3.34.tar.bz2 Resolving pkg-isocodes.alioth.debian.org... 5.153.231.21 Connecting to pkg-isocodes.alioth.debian.org|5.153.231.21|:80... connected. HTTP request sent, awaiting response... 404 Not Found 2013-12-23 19:48:03 ERROR 404: Not Found. I discovered that the versiou available on the website is now 3.49 and an .xz file. So I updated custom.sh ISOCODES_URL=http://pkg-isocodes.alioth.debian.org/downloads/iso-codes-3.49.tar.xz; and edited functions.sh to include at line 92: *.tar.xz) tar -xJpf $LAST_FILE -C $_EXTRACT_UDIR _PACK_DIR=$(tar -Jtf $LAST_FILE 2/dev/null | head -1) ;; and carried on Next it refused to install html help because a newer version was already on the machine. but that didn't sound too serious. So it carried on until extracting libdbi-0.8.4.tar.gz ... done Hunk #2 FAILED at 154 1 out of 4 hunks FAILED Will look further later. Gary So I assume something's moved ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Building on Windows from scratch
So it carried on until extracting libdbi-0.8.4.tar.gz ... done Hunk #2 FAILED at 154 1 out of 4 hunks FAILED Will look further later. Odd I could build. But then again I did so many rebuilds, perhaps I worked with a different patch than what I eventually committed. Thanks for looking at this ! Geert Another update. - The problem with libdbi goes away if you change the patch command on line 792 and again on line 828 to include -l patch -l -p1 .. I assume there's some weird whitespace problem with either the patch of the current version of the code - There seems to be a version issue with GWENHYFAR_VERSION It builds OK but every time I restart it rebuilds. For some reason it's built a version which annouces itself as 4.7.0beta even though the file it downloads says it's 4.8.0beta If I build and change the version to 4.7.0beta it doesn't then try and rebuild each time. But seems a bit strange. Finally, it tries to build gnucash itself. The first sign of a problem is that it says: please add the files codeset.m4 gettext.m4 glibc21.m4 iconf.m4 isc-posix.m4 lcmessage.m4 progtest.m4 from the /aclocal directory to your autoconf macro directory or directly to your aclocal.m4 file And then You shoudl add the contents of /c/soft/gnome/share/aclocal/intltool.m4 to aclocal.m4 . Running autoconf NOTE: Just run configure. Even if something told you to run aclocal, autommake. You must now run ./configure --enable-compile-warnings ./install-impl.sh: lin 1296: ../repos/configure: No such file or directory. Not sure if this is where you are at this point too Gary ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
RE: Building on Windows from scratch
Thanks for the info. I will set up a windows 32 bit virtual machine and try to follow the instructions one by one. Should I report each problem to this list or privately to somewhere else. I'm happy to put in the work to ensure that the instructions are clear. BTW, the reason I want to be able to build gnucash from source is that I'm considering some enhancements which may be of interest to others and may not, but I am restricted to running on windows boxes at the moment. Gary -Original message- From:Christian Stimming christ...@cstimming.de Sent:Thu 19-12-2013 20:04 Subject:Re: Building on Windows from scratch To:gnucash-devel@gnucash.org; CC:Gary Bilkus m...@gary.bilkus.com; Dear Gary, I've used those instructions several times, and quite successfully each time (although it takes hours). Am Donnerstag, 19. Dezember 2013, 09:36:28 schrieb Gary Bilkus: Has anyone actually succeeded in following the instructions on the wiki page http://wiki.gnucash.org/wiki/Windows/Development I'm running Windows 7 64 bit. Almost every stage seems to fail - wget won't download automatically, crypt libraries are missing when you get wget, other libraries don't compile. I follow various threads to fix the problems, and finally get an executable which just crashes. I think the 64-bit part causes quite some issues for you. The binaries are almost surely not 64-bit capable and those might result in many of the problems you're facing. Other than that, we could just ask you to list the problems, one by one and in detail, so that one by one those get fixed again, or extended so that win7 64bit works as well. Regards, Christian ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
RE: Building on Windows from scratch
I will probably set up a dedicated linux box to do any actual development, but the end result has to work for other people who only have Windows knowledge and are not willing to mess around with virtual systems etc. Since I have no right to expect that any changes I make will end up in the official build, I need to satisfy myself that I can build on Windows first. Gary -Original message- From:Colin Law clan...@gmail.com Sent:Fri 20-12-2013 13:27 Subject:Re: Building on Windows from scratch To:Gary Bilkus m...@gary.bilkus.com; CC:gnucash-devel@gnucash.org; Christian Stimming christ...@cstimming.de; On 20 December 2013 12:59, Gary Bilkus m...@gary.bilkus.com wrote: Thanks for the info. I will set up a windows 32 bit virtual machine and try to follow the instructions one by one. Should I report each problem to this list or privately to somewhere else. I'm happy to put in the work to ensure that the instructions are clear. BTW, the reason I want to be able to build gnucash from source is that I'm considering some enhancements which may be of interest to others and may not, but I am restricted to running on windows boxes at the moment. Have you considered running ubuntu (for example) in a virtual machine such as vmware or virtualbox? I suspect the hassle of doing that would be much less than that of developing on Windows. Colin ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
RE: Building on Windows from scratch
Hi Geert, If you're already well into solving the problem, I'd be very happy to try and help with that effort. I will take a look at your repository at some point during the next few days. Would you expect this to work under 64 bit versions of Windows, or are the other comments about this still relevant? I must say I'm a bit confused that some replies, like that from Christian suggest that it should just work under the right Windows, whereas you're implying it doesn't, presumably at least partly because the various needed repositories are out of sync with the instructions. Have I understood correctly. Thanks, Gary -Original message- From:Geert Janssens janssens-ge...@telenet.be Sent:Fri 20-12-2013 17:16 Subject:Re: Building on Windows from scratch To:gnucash-devel@gnucash.org; On Friday 20 December 2013 14:25:26 Gary Bilkus wrote: I will probably set up a dedicated linux box to do any actual development, but the end result has to work for other people who only have Windows knowledge and are not willing to mess around with virtual systems etc. Since I have no right to expect that any changes I make will end up in the official build, I need to satisfy myself that I can build on Windows first. Gary Gary, Thank you for your interest in working on GnuCash on Windows. I have been working for some time on making this easier in a private repository. I won't get this ready in time for the pending 2.6 release, but expect this to be available somewhere in January/February 2014. The changes I'm talking about are pretty fundamental, like instead of having to go through several manual steps to get started, I created one single bootstrap script that should get you going. I updated the base mingw environment to much more recent tool versions,... It's not ready yet. I'm currently at the point that all dependencies build successfully in the updated environment, but gnucash itself still fails to build. This is not helping you right now with your attempt to build gnucash on Windows. I'm mostly bringing it up for a couple reasons: - you may want to postphone your experiments a few months to enjoy the improved setup. - with this overhaul getting near, it may not make much sense to try and fix the old build environment. - or you may be interested in helping out on getting this branch fixed. I have pushed it to https://github.com/gjanssens/gnucash/tree/mingw-rebasing for now. Geert ___ 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
Building on Windows from scratch
Has anyone actually succeeded in following the instructions on the wiki page http://wiki.gnucash.org/wiki/Windows/Development from scratch and ending up with a working gnucash. Or is there some other hidden set of instructions. I have tried to build gnucash on windows several times and have never succeeded. It's clearly possible, because there's a windows version out there. So what's the secret? All I can see in the archives are various other people who have problems, no complete solution. I'm running Windows 7 64 bit. Almost every stage seems to fail - wget won't download automatically, crypt libraries are missing when you get wget, other libraries don't compile. I follow various threads to fix the problems, and finally get an executable which just crashes. Surely someone must know how to do this correctly? Thanks, Gary ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
