Re: Windows build failed to build new aqbanking 5.7.8

[Christian Stimming]

I've committed this patch to aqbanking, so that it will appear in a 
aqbanking-5.7.9 version when it comes out sometime in the future.

Regards,
Christian

Am Freitag, 30. März 2018, 06:53:32 schrieb John Ralls:
> There’s a type error in AQBanking on windows that stops the AQB build and I
> haven’t yet added the patch to the build, though I did report it to Martin.
> 
> The patch is attached.
> 
> Regards,
> John Ralls
> 
> > On Mar 30, 2018, at 5:13 AM, Robert Fewell <14ubo...@gmail.com> wrote:
> > 
> > Was looking to see if the new version of aqbabking 5.7.8 fixes combobox
> > issue but it fails to build. The new Gwenhywfar 4.20 builds OK and this
> > has
> > the gtk3 stuff in it.
> > There were some errors about creating symlinks due to the files already
> > being there which I suppose one can ignore but later it fails.
> > Looked at the build server logs and it has the same failure.
> > 
> > Bob
> > ___
> > 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: Windows build failed to build new aqbanking 5.7.8

[Robert Fewell]

Thank you for the patch, that fixed the build but still the same with
aqbanking combo's.
Will see if I can find out what is happening.

Bob

On 30 March 2018 at 14:53, John Ralls  wrote:

> There’s a type error in AQBanking on windows that stops the AQB build and
> I haven’t yet added the patch to the build, though I did report it to
> Martin.
>
> The patch is attached.
>
> Regards,
> John Ralls
>
> > On Mar 30, 2018, at 5:13 AM, Robert Fewell <14ubo...@gmail.com> wrote:
> >
> > Was looking to see if the new version of aqbabking 5.7.8 fixes combobox
> > issue but it fails to build. The new Gwenhywfar 4.20 builds OK and this
> has
> > the gtk3 stuff in it.
> > There were some errors about creating symlinks due to the files already
> > being there which I suppose one can ignore but later it fails.
> > Looked at the build server logs and it has the same failure.
> >
> > Bob
> > ___
> > 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: Windows build failed to build new aqbanking 5.7.8

[John Ralls]

There’s a type error in AQBanking on windows that stops the AQB build and I 
haven’t yet added the patch to the build, though I did report it to Martin.

The patch is attached.

Regards,
John Ralls

> On Mar 30, 2018, at 5:13 AM, Robert Fewell <14ubo...@gmail.com> wrote:
> 
> Was looking to see if the new version of aqbabking 5.7.8 fixes combobox
> issue but it fails to build. The new Gwenhywfar 4.20 builds OK and this has
> the gtk3 stuff in it.
> There were some errors about creating symlinks due to the files already
> being there which I suppose one can ignore but later it fails.
> Looked at the build server logs and it has the same failure.
> 
> Bob
> ___
> gnucash-devel mailing list
> gnucash-devel@gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel


Fix-signature-mismatch-in-abgui.c.patch
Description: Binary data
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Windows Build

[Robert Fewell]

Geert,

Regarding 1, I made local changes when I found it last month but forgot
about it.
Regarding 2, I cheated as mentioned in my posting last month,

in i686-w64-mingw32/include/wincrypt.h there is a define for
X509_NAME, I temporarily renamed it and was able to build xmlsec and
continue to build GnuCash and create steup.exe for it which installed
fine

Regards,
  Bob


On 5 March 2018 at 21:07, Geert Janssens  wrote:

> Op maandag 5 maart 2018 18:41:38 CET schreef Geert Janssens:
> > Op maandag 5 maart 2018 12:10:48 CET schreef Robert Fewell:
> > > Geert,
> > >
> > > I have successfully built a 2.7.5 version locally with these changes...
> > >
> > > Added the following to gnome/CMakeLists.txt at line 178 but I think
> this
> > > may need to go in the jhbuildrc.in file
> > > GETTEXTDATADIR=/mingw32/share/gettext
> >
> > Yes, I figured jhbuildrc.in would be a good candidate. I'm playing with
> > manipulating XDG_DATA_DIRS rather than GETTEXTDATADIR now for the same
> > effect. It should be more useful as there's more in /mingw32/share than
> > gettext data.
> >
> > Also, I have generalized it a bit to work for both 32 as 64 bit builds.
> >
> > > Added the following to gnucash-mingw64.iss at line 120
> > > Source: "@MINGW_DIR@\bin\libboost_date_time-mt.dll"; DestDir:
> "{app}\bin";
> > > Components: main
> >
> > Ok. I didn't understand your first mail correctly. Your fix makes sense
> now.
> > > Whilst poking around yesterday I also created copies of
> > > gettext/its/appdata.its/loc as it appeared to me the loc file was doing
> > > file matching but the match pattern was *.appdata.xml and not *.
> > > appdata.xml.in
> > > but this may not be required, need to delete these extra files and try
> > > another rebuild.
> >
> > This is probably not required. gettext tools will remove any .in
> extension
> > before determining the file type. It's like that on linux as well and it
> > works fine there.
> >
> > > Have you run the *setup-ming64-ps1 *file, I did last month and as
> reported
> > > made some changes which effected the build, namely I think cmake was
> > > updated to 10 which meant the FindSWIG patch would not apply so maybe
> > > there
> > > were other changes that affected gettext ?
> >
> > I didn't run setup-mingw64.ps1 and that was an important clue. Indeed it
> > looks like FindGettext.cmake has been updated to take an optional .exe
> into
> > account.
> >
> > The FindSWIG patch won't apply because it tries to look for a file in
> > cmake-3.9 while the files are now in cmake-3.10. I'm holding off on
> > adjusting the patch because it appears you didn't need it any more.
> >
> > Waiting for the build to finish (once more).
> >
>
> So some final updates:
>
> 1. The FindSWIG patch is still necessary. I have adapted it to work with
> cmake
> 3.10. I don't know how Bob got past that on his local build. Perhaps the
> values were still cached?
>
> 2. I have rerun setup-minw64.ps1 several times to get all non-jhbuild
> managed
> packages up to date. It took several runs because the first run updated
> msys2,
> which had new mingw packages in its package list, but the first run had
> already determined what to update. I believe my local box and the gnucash
> build server are now fully up to date.
>
> With that and my other patches in place...
>
> 2. I can't get a successful build on my local Windows 7 box. It fails to
> build
> xmlsec. I tried wiping it and restarting the build, but it consistently
> fails
> on
> file xmlsec-xmlsec_1_2_20/src/openssl/x509.c:94
> Error: expected declaration specifiers or '...' before '(' token
> static xmlChar* xmlSecOpenSSLX509NameWrite (X509_NAME* nm);
>
> The error points at the the X in X509_NAME. This triggers a whole set of
> other
> warnings which I won't repeat here.
>
> 3. Since I didn't manage to get my Win7 box to build this, I decided to
> try on
> the build server. This has no issues with xmlsec (unless it didn't retry,
> but
> I think it did). It consistently fails however when building gnucash. The
> error log can be seen here:
> https://code.gnucash.org/builds/win32/build-logs/build-
> unstable-2018-03-05-14-46-47.log
>
> Again I tried completely wiping the current build dir, but it still fails.
> So
> again I'm surprised Bob did get past this.
>
> I don't know how to proceed from here (yet) and I don't know when I will
> have
> time to continue this.
>
> If anyone else wants to take a stab at this, please go ahead.
>
> 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

Re: Windows Build

[Geert Janssens]

Op maandag 5 maart 2018 18:41:38 CET schreef Geert Janssens:
> Op maandag 5 maart 2018 12:10:48 CET schreef Robert Fewell:
> > Geert,
> > 
> > I have successfully built a 2.7.5 version locally with these changes...
> > 
> > Added the following to gnome/CMakeLists.txt at line 178 but I think this
> > may need to go in the jhbuildrc.in file
> > GETTEXTDATADIR=/mingw32/share/gettext
> 
> Yes, I figured jhbuildrc.in would be a good candidate. I'm playing with
> manipulating XDG_DATA_DIRS rather than GETTEXTDATADIR now for the same
> effect. It should be more useful as there's more in /mingw32/share than
> gettext data.
> 
> Also, I have generalized it a bit to work for both 32 as 64 bit builds.
> 
> > Added the following to gnucash-mingw64.iss at line 120
> > Source: "@MINGW_DIR@\bin\libboost_date_time-mt.dll"; DestDir: "{app}\bin";
> > Components: main
> 
> Ok. I didn't understand your first mail correctly. Your fix makes sense now.
> > Whilst poking around yesterday I also created copies of
> > gettext/its/appdata.its/loc as it appeared to me the loc file was doing
> > file matching but the match pattern was *.appdata.xml and not *.
> > appdata.xml.in
> > but this may not be required, need to delete these extra files and try
> > another rebuild.
> 
> This is probably not required. gettext tools will remove any .in extension
> before determining the file type. It's like that on linux as well and it
> works fine there.
> 
> > Have you run the *setup-ming64-ps1 *file, I did last month and as reported
> > made some changes which effected the build, namely I think cmake was
> > updated to 10 which meant the FindSWIG patch would not apply so maybe
> > there
> > were other changes that affected gettext ?
> 
> I didn't run setup-mingw64.ps1 and that was an important clue. Indeed it
> looks like FindGettext.cmake has been updated to take an optional .exe into
> account.
> 
> The FindSWIG patch won't apply because it tries to look for a file in
> cmake-3.9 while the files are now in cmake-3.10. I'm holding off on
> adjusting the patch because it appears you didn't need it any more.
> 
> Waiting for the build to finish (once more).
> 

So some final updates:

1. The FindSWIG patch is still necessary. I have adapted it to work with cmake 
3.10. I don't know how Bob got past that on his local build. Perhaps the 
values were still cached?

2. I have rerun setup-minw64.ps1 several times to get all non-jhbuild managed 
packages up to date. It took several runs because the first run updated msys2, 
which had new mingw packages in its package list, but the first run had 
already determined what to update. I believe my local box and the gnucash 
build server are now fully up to date.

With that and my other patches in place...

2. I can't get a successful build on my local Windows 7 box. It fails to build 
xmlsec. I tried wiping it and restarting the build, but it consistently fails 
on
file xmlsec-xmlsec_1_2_20/src/openssl/x509.c:94
Error: expected declaration specifiers or '...' before '(' token 
static xmlChar* xmlSecOpenSSLX509NameWrite (X509_NAME* nm);

The error points at the the X in X509_NAME. This triggers a whole set of other 
warnings which I won't repeat here.

3. Since I didn't manage to get my Win7 box to build this, I decided to try on 
the build server. This has no issues with xmlsec (unless it didn't retry, but 
I think it did). It consistently fails however when building gnucash. The 
error log can be seen here:
https://code.gnucash.org/builds/win32/build-logs/build-unstable-2018-03-05-14-46-47.log

Again I tried completely wiping the current build dir, but it still fails. So 
again I'm surprised Bob did get past this.

I don't know how to proceed from here (yet) and I don't know when I will have 
time to continue this.

If anyone else wants to take a stab at this, please go ahead.

Geert


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Windows Build

[Geert Janssens]

Op maandag 5 maart 2018 12:10:48 CET schreef Robert Fewell:
> Geert,
> 
> I have successfully built a 2.7.5 version locally with these changes...
> 
> Added the following to gnome/CMakeLists.txt at line 178 but I think this
> may need to go in the jhbuildrc.in file
> GETTEXTDATADIR=/mingw32/share/gettext
> 
Yes, I figured jhbuildrc.in would be a good candidate. I'm playing with 
manipulating XDG_DATA_DIRS rather than GETTEXTDATADIR now for the same effect. 
It should be more useful as there's more in /mingw32/share than gettext data.

Also, I have generalized it a bit to work for both 32 as 64 bit builds.

> Added the following to gnucash-mingw64.iss at line 120
> Source: "@MINGW_DIR@\bin\libboost_date_time-mt.dll"; DestDir: "{app}\bin";
> Components: main
> 
Ok. I didn't understand your first mail correctly. Your fix makes sense now.

> Whilst poking around yesterday I also created copies of
> gettext/its/appdata.its/loc as it appeared to me the loc file was doing
> file matching but the match pattern was *.appdata.xml and not *.
> appdata.xml.in
> but this may not be required, need to delete these extra files and try
> another rebuild.
> 
This is probably not required. gettext tools will remove any .in extension 
before determining the file type. It's like that on linux as well and it works 
fine there.

> Have you run the *setup-ming64-ps1 *file, I did last month and as reported
> made some changes which effected the build, namely I think cmake was
> updated to 10 which meant the FindSWIG patch would not apply so maybe there
> were other changes that affected gettext ?
> 
I didn't run setup-mingw64.ps1 and that was an important clue. Indeed it looks 
like FindGettext.cmake has been updated to take an optional .exe into account.

The FindSWIG patch won't apply because it tries to look for a file in 
cmake-3.9 while the files are now in cmake-3.10. I'm holding off on adjusting 
the patch because it appears you didn't need it any more.

Waiting for the build to finish (once more).

Geert


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Windows Build

[Geert Janssens]

Op zondag 4 maart 2018 20:57:54 CET schreef Geert Janssens:
> Op zondag 4 maart 2018 17:40:08 CET schreef Geert Janssens:
> > Op zondag 4 maart 2018 16:19:46 CET schreef Robert Fewell:
> > > Hi all,
> > > 
> > > Just tried to build the latest unstable for Windows but it fails with
> > > this
> > > ...
> > > 
> > > [ 76%] Generating gnucash.appdata.xml
> > > C:/gcdev64/msys2/mingw32/bin/msgfmt.exe: cannot locate ITS rules for
> > > C:/gcdev64/gnucash/unstable/src/gnucash-git/gnucash/gnome/
> > > gnucash.appdata.xml.in
> > > make[2]: ***
> > > [gnucash/gnome/CMakeFiles/gnucash-appdata.dir/build.make:61:
> > > gnucash/gnome/gnucash.appdata.xml] Error 1
> > > make[1]: *** [CMakeFiles/Makefile2:7919:
> > > gnucash/gnome/CMakeFiles/gnucash-appdata.dir/all] Error 2
> > > make: *** [Makefile:163: all] Error 2
> > > *** Error during phase build of gnucash-git: ## Error running
> > > make
> > > -j 1  *** [15/17]
> > > 
> > > Poked around but could not get it to work so thought I would see what
> > > the
> > > build server logs yield but that has not worked since 25/02/2018 so no
> > > help
> > > there.
> > 
> > This probably means msgfmt is not finding gettext's its rules. On linux
> > they are in /usr/share/gettext/its and/or /usr/share/gettext-0.19.8/its.
> > 
> > I had to search a bit on the windows build server. Apparently there they
> > are stored under /mingw32/share/gettext/its which for some reason is not
> > where msgfmt is expecting them. We can fix this by setting environment
> > variable GETTEXTDATADIR to /mingw32/share/gettext somewhere that it's in
> > the environment when gnucash is being built. I don't know offhand how to
> > do that exactly in jhbuild.
> > 
> > > So I downloaded that build but it fails with a missing
> > > libboost_date_time-mt.dll so if the above is fixed it still might not
> > > work.
> > 
> > Interesting. The build server's build failure is a gettext issue as well.
> > It fails to compare GETTEXT_VERSION_STRING to 0.19. Or more precisely it
> > seems like GETTEXT_VERSION_STRING is not being set.
> 
> FYI, I'm in the process of rerunning my own unstable build, but it looks
> like it will still take a few hours...
> 
> ..
> 
> > > Also the maint
> > > build is complaining about certificates and gives up.
> > 
> > Hmm, looks like our download script isn't happy with the new certificate
> > being used at aquamaniac.  It appears the download function we use is not
> > smart enough to read Alternative DNS names from the certificate... To be
> > investigated...
> 
> I have looked at the maint issue. I tried adding "--no-check-certificates",
> but that didn't make any difference. The issue is not the certificate not
> being accepted, on the mingw version of wget it's merely a warning. But for
> some reason wget doesn't get any response from the aquamaniac website. So it
> retries 20 times and then gives up.
> To work around this, I have manually downloaded the necessary gwenhywfar and
> aqbanking packages and stored them in the downloads directory for the maint
> build. As we're targeting only one last maint release, that should do.

The workaround works with gwenhywfar 4.18.0 and aqbanking 5.7.6beta. I also 
tried upgrading to gwen 4.20.0 and aqbanking 5.8, but that results in a build 
failure due to some conflicting data type. So for now I have reverted to the 
older two versions.

Geert


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Windows Build

[Robert Fewell]

Geert,

I have successfully built a 2.7.5 version locally with these changes...

Added the following to gnome/CMakeLists.txt at line 178 but I think this
may need to go in the jhbuildrc.in file
GETTEXTDATADIR=/mingw32/share/gettext

Added the following to gnucash-mingw64.iss at line 120
Source: "@MINGW_DIR@\bin\libboost_date_time-mt.dll"; DestDir: "{app}\bin";
Components: main

Whilst poking around yesterday I also created copies of
gettext/its/appdata.its/loc as it appeared to me the loc file was doing
file matching but the match pattern was *.appdata.xml and not *.
appdata.xml.in
but this may not be required, need to delete these extra files and try
another rebuild.

Have you run the *setup-ming64-ps1 *file, I did last month and as reported
made some changes which effected the build, namely I think cmake was
updated to 10 which meant the FindSWIG patch would not apply so maybe there
were other changes that affected gettext ?


I will have another go later, need to prepare car for MOT tomorrow.

Regards,
Bob



On 4 March 2018 at 16:40, Geert Janssens  wrote:

> Op zondag 4 maart 2018 16:19:46 CET schreef Robert Fewell:
> > Hi all,
> >
> > Just tried to build the latest unstable for Windows but it fails with
> this
> > ...
> >
> > [ 76%] Generating gnucash.appdata.xml
> > C:/gcdev64/msys2/mingw32/bin/msgfmt.exe: cannot locate ITS rules for
> > C:/gcdev64/gnucash/unstable/src/gnucash-git/gnucash/gnome/
> > gnucash.appdata.xml.in
> > make[2]: *** [gnucash/gnome/CMakeFiles/gnucash-appdata.dir/build.
> make:61:
> > gnucash/gnome/gnucash.appdata.xml] Error 1
> > make[1]: *** [CMakeFiles/Makefile2:7919:
> > gnucash/gnome/CMakeFiles/gnucash-appdata.dir/all] Error 2
> > make: *** [Makefile:163: all] Error 2
> > *** Error during phase build of gnucash-git: ## Error running
> make
> > -j 1  *** [15/17]
> >
> > Poked around but could not get it to work so thought I would see what the
> > build server logs yield but that has not worked since 25/02/2018 so no
> help
> > there.
> >
> This probably means msgfmt is not finding gettext's its rules. On linux
> they
> are in /usr/share/gettext/its and/or /usr/share/gettext-0.19.8/its.
>
> I had to search a bit on the windows build server. Apparently there they
> are
> stored under /mingw32/share/gettext/its which for some reason is not where
> msgfmt is expecting them. We can fix this by setting environment variable
> GETTEXTDATADIR to /mingw32/share/gettext somewhere that it's in the
> environment when gnucash is being built. I don't know offhand how to do
> that
> exactly in jhbuild.
>
>
> > So I downloaded that build but it fails with a missing
> > libboost_date_time-mt.dll so if the above is fixed it still might not
> work.
> >
> Interesting. The build server's build failure is a gettext issue as well.
> It
> fails to compare GETTEXT_VERSION_STRING to 0.19. Or more precisely it seems
> like GETTEXT_VERSION_STRING is not being set.
>
> Did you not get this error in your cmake run locally ?
>
> Geert
>
> > PS: Is it possible to clear out some of the old logs, maybe separate
> > sub-directories for each maint, master, unstable and docs.
>
> That should be something for Derek to look into...
>
> > Also the maint
> > build is complaining about certificates and gives up.
>
> Hmm, looks like our download script isn't happy with the new certificate
> being
> used at aquamaniac.  It appears the download function we use is not smart
> enough to read Alternative DNS names from the certificate... To be
> investigated...
>
> Unless you plan to dig into these yourself, can you file bug reports ?
>
> Thanks
>
>
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Windows build

[John Ralls]

> On Mar 4, 2018, at 5:33 PM, Phil Longstaff  wrote:
> 
> I ran setup-ming64.ps1 -x86_64 $true -target_dir d:\gcdev64. It complained
> about conflicts between msys2-runtime and catgets, but did seem to complete
> successfully. It left me with instructions to start a MSys2/Mingw32 shell,
> cd to my target directory, and run a jhbuild command. When I do this,
> jhbuild returns almost immediately and seems to do nothing.
> 
> Is there more setup I need to do? I am somewhat familiar with the old
> windows build system, but not the new one.

Phil,

If you do -x86_64 $true you need to start an MSYS2/Mingw64 shell.

Regards,
John Ralls
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Windows Build

[Geert Janssens]

Op zondag 4 maart 2018 20:57:54 CET schreef Geert Janssens:
> Op zondag 4 maart 2018 17:40:08 CET schreef Geert Janssens:
> > Op zondag 4 maart 2018 16:19:46 CET schreef Robert Fewell:
> > > Hi all,
> > > 
> > > Just tried to build the latest unstable for Windows but it fails with
> > > this
> > > ...
> > > 
> > > [ 76%] Generating gnucash.appdata.xml
> > > C:/gcdev64/msys2/mingw32/bin/msgfmt.exe: cannot locate ITS rules for
> > > C:/gcdev64/gnucash/unstable/src/gnucash-git/gnucash/gnome/
> > > gnucash.appdata.xml.in
> > > make[2]: ***
> > > [gnucash/gnome/CMakeFiles/gnucash-appdata.dir/build.make:61:
> > > gnucash/gnome/gnucash.appdata.xml] Error 1
> > > make[1]: *** [CMakeFiles/Makefile2:7919:
> > > gnucash/gnome/CMakeFiles/gnucash-appdata.dir/all] Error 2
> > > make: *** [Makefile:163: all] Error 2
> > > *** Error during phase build of gnucash-git: ## Error running
> > > make
> > > -j 1  *** [15/17]
> > > 
> > > Poked around but could not get it to work so thought I would see what
> > > the
> > > build server logs yield but that has not worked since 25/02/2018 so no
> > > help
> > > there.
> > 
> > This probably means msgfmt is not finding gettext's its rules. On linux
> > they are in /usr/share/gettext/its and/or /usr/share/gettext-0.19.8/its.
> > 
> > I had to search a bit on the windows build server. Apparently there they
> > are stored under /mingw32/share/gettext/its which for some reason is not
> > where msgfmt is expecting them. We can fix this by setting environment
> > variable GETTEXTDATADIR to /mingw32/share/gettext somewhere that it's in
> > the environment when gnucash is being built. I don't know offhand how to
> > do that exactly in jhbuild.
> > 
> > > So I downloaded that build but it fails with a missing
> > > libboost_date_time-mt.dll so if the above is fixed it still might not
> > > work.
> > 
> > Interesting. The build server's build failure is a gettext issue as well.
> > It fails to compare GETTEXT_VERSION_STRING to 0.19. Or more precisely it
> > seems like GETTEXT_VERSION_STRING is not being set.

I'm surprised you even got past the gnucash configuration step in your build. 
I have just gotten there and it appears there's a bug in cmake's FindGettext 
module. It parses the output of msgfmt --version command to extract the 
gettext version.
However the regex it uses to parse this is not correct on Windows/MSys2.
The output on linux is:
msgfmt (GNU gettext-tools) 0.19.8.1
while on Windows it becomes:
msgfmt.exe (GNU gettext-tools) 0.19.8.1

The regex doesn't take the optional/additional '.exe' into account and as a 
result will fail to set GETTEXT_VERSION_STRING

I have manually added .exe in msys2\mingw32\share\cmake-3.9\Modules
\FindGettext.cmake
Just to try and continue the build. That works but now it fails on compiling 
gettext.scm. Unfortunately I'm out of time for now.

So next steps would be:
1. figuring out who to contact to report the bug in FindGettext
2. make a temporary workaround for it while we wait for an official fix
3. figure out why gettext.scm fails to build.

Geert


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Windows Build

[Geert Janssens]

Op zondag 4 maart 2018 17:40:08 CET schreef Geert Janssens:
> Op zondag 4 maart 2018 16:19:46 CET schreef Robert Fewell:
> > Hi all,
> > 
> > Just tried to build the latest unstable for Windows but it fails with this
> > ...
> > 
> > [ 76%] Generating gnucash.appdata.xml
> > C:/gcdev64/msys2/mingw32/bin/msgfmt.exe: cannot locate ITS rules for
> > C:/gcdev64/gnucash/unstable/src/gnucash-git/gnucash/gnome/
> > gnucash.appdata.xml.in
> > make[2]: *** [gnucash/gnome/CMakeFiles/gnucash-appdata.dir/build.make:61:
> > gnucash/gnome/gnucash.appdata.xml] Error 1
> > make[1]: *** [CMakeFiles/Makefile2:7919:
> > gnucash/gnome/CMakeFiles/gnucash-appdata.dir/all] Error 2
> > make: *** [Makefile:163: all] Error 2
> > *** Error during phase build of gnucash-git: ## Error running make
> > -j 1  *** [15/17]
> > 
> > Poked around but could not get it to work so thought I would see what the
> > build server logs yield but that has not worked since 25/02/2018 so no
> > help
> > there.
> 
> This probably means msgfmt is not finding gettext's its rules. On linux they
> are in /usr/share/gettext/its and/or /usr/share/gettext-0.19.8/its.
> 
> I had to search a bit on the windows build server. Apparently there they are
> stored under /mingw32/share/gettext/its which for some reason is not where
> msgfmt is expecting them. We can fix this by setting environment variable
> GETTEXTDATADIR to /mingw32/share/gettext somewhere that it's in the
> environment when gnucash is being built. I don't know offhand how to do
> that exactly in jhbuild.
> 
> > So I downloaded that build but it fails with a missing
> > libboost_date_time-mt.dll so if the above is fixed it still might not
> > work.
> 
> Interesting. The build server's build failure is a gettext issue as well. It
> fails to compare GETTEXT_VERSION_STRING to 0.19. Or more precisely it seems
> like GETTEXT_VERSION_STRING is not being set.
> 

FYI, I'm in the process of rerunning my own unstable build, but it looks like 
it will still take a few hours...

..

> > Also the maint
> > build is complaining about certificates and gives up.
> 
> Hmm, looks like our download script isn't happy with the new certificate
> being used at aquamaniac.  It appears the download function we use is not
> smart enough to read Alternative DNS names from the certificate... To be
> investigated...
> 
I have looked at the maint issue. I tried adding "--no-check-certificates", 
but that didn't make any difference. The issue is not the certificate not 
being accepted, on the mingw version of wget it's merely a warning. But for 
some reason wget doesn't get any response from the aquamaniac website. So it 
retries 20 times and then gives up.
To work around this, I have manually downloaded the necessary gwenhywfar and 
aqbanking packages and stored them in the downloads directory for the maint 
build. As we're targeting only one last maint release, that should do.


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Windows Build

[Geert Janssens]

Op zondag 4 maart 2018 16:19:46 CET schreef Robert Fewell:
> Hi all,
> 
> Just tried to build the latest unstable for Windows but it fails with this
> ...
> 
> [ 76%] Generating gnucash.appdata.xml
> C:/gcdev64/msys2/mingw32/bin/msgfmt.exe: cannot locate ITS rules for
> C:/gcdev64/gnucash/unstable/src/gnucash-git/gnucash/gnome/
> gnucash.appdata.xml.in
> make[2]: *** [gnucash/gnome/CMakeFiles/gnucash-appdata.dir/build.make:61:
> gnucash/gnome/gnucash.appdata.xml] Error 1
> make[1]: *** [CMakeFiles/Makefile2:7919:
> gnucash/gnome/CMakeFiles/gnucash-appdata.dir/all] Error 2
> make: *** [Makefile:163: all] Error 2
> *** Error during phase build of gnucash-git: ## Error running make
> -j 1  *** [15/17]
> 
> Poked around but could not get it to work so thought I would see what the
> build server logs yield but that has not worked since 25/02/2018 so no help
> there.
> 
This probably means msgfmt is not finding gettext's its rules. On linux they 
are in /usr/share/gettext/its and/or /usr/share/gettext-0.19.8/its.

I had to search a bit on the windows build server. Apparently there they are 
stored under /mingw32/share/gettext/its which for some reason is not where 
msgfmt is expecting them. We can fix this by setting environment variable 
GETTEXTDATADIR to /mingw32/share/gettext somewhere that it's in the 
environment when gnucash is being built. I don't know offhand how to do that 
exactly in jhbuild.


> So I downloaded that build but it fails with a missing
> libboost_date_time-mt.dll so if the above is fixed it still might not work.
> 
Interesting. The build server's build failure is a gettext issue as well. It 
fails to compare GETTEXT_VERSION_STRING to 0.19. Or more precisely it seems 
like GETTEXT_VERSION_STRING is not being set.

Did you not get this error in your cmake run locally ?

Geert

> PS: Is it possible to clear out some of the old logs, maybe separate
> sub-directories for each maint, master, unstable and docs.

That should be something for Derek to look into...

> Also the maint
> build is complaining about certificates and gives up.

Hmm, looks like our download script isn't happy with the new certificate being 
used at aquamaniac.  It appears the download function we use is not smart 
enough to read Alternative DNS names from the certificate... To be 
investigated...

Unless you plan to dig into these yourself, can you file bug reports ?

Thanks


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Windows build Unstable Fails

[Robert Fewell]

A follow up, in i686-w64-mingw32/include/wincrypt.h there is a define for
X509_NAME, I temporarily renamed it and was able to build xmlsec and
continue to build GnuCash and create steup.exe for it which installed fine.
I have noticed a couple of issues with the register colours which I will
investigate and add fix to a PR.

Bob

On 4 February 2018 at 22:54, Robert Fewell <14ubo...@gmail.com> wrote:

> Hi,
>
> I thought I would build the latest Windows unstable version to prove some
> changes I was going to make but it failed as follows...
>
> I ran setup-ming64-ps1 which updated the core system files as usual and
> this completed OK. Probably my first mistake, should of kept the system
> files at a known working level but I suppose someone building from scratch
> would get the latest system files.
>
> Tried to use the jhbuild command which I think updated some AqBanking
> parts, and then started the Gnucash build. There were some references to
> boost dependencies as I think that was updated and then a failure to find
> Swig. Fixed that by applying the SwigPatch to new version of cmake-3.10 and
> then it failed on one of the scheme files.
>
> I think I had that sort of error before so I deleted the unstable folder
> and started to build it all again but xmlsec fails to build with the
> following error...
>
> In file included from C:/gcdev64/msys2/mingw32/i686-
> w64-mingw32/include/windows.h:95:0,
>  from C:/gcdev64/msys2/mingw32/
> include/libxslt/xsltlocale.h:43,
>  from C:/gcdev64/msys2/mingw32/
> include/libxslt/xsltInternals.h:24,
>  from C:/gcdev64/msys2/mingw32/
> include/libxslt/security.h:17,
>  from C:/gcdev64/gnucash/unstable/
> src/xmlsec-xmlsec-1_2_20/include/xmlsec/transforms.h:953,
>  from C:/gcdev64/gnucash/unstable/
> src/xmlsec-xmlsec-1_2_20/include/xmlsec/keyinfo.h:27,
>  from C:/gcdev64/gnucash/unstable/
> src/xmlsec-xmlsec-1_2_20/src/openssl/x509.c:33:
> C:/gcdev64/gnucash/unstable/src/xmlsec-xmlsec-1_2_20/src/openssl/x509.c:94:66:
> error: expected declaration specifiers or '...' before '(' token
>  static xmlChar* xmlSecOpenSSLX509NameWrite
> (X509_NAME* nm);
>   ^
> In file included from C:/gcdev64/msys2/mingw32/i686-
> w64-mingw32/include/windows.h:95:0,
>  from C:/gcdev64/msys2/mingw32/
> include/libxslt/xsltlocale.h:43,
>  from C:/gcdev64/msys2/mingw32/
> include/libxslt/xsltInternals.h:24,
>  from C:/gcdev64/msys2/mingw32/
> include/libxslt/security.h:17,
>  from C:/gcdev64/gnucash/unstable/
> src/xmlsec-xmlsec-1_2_20/include/xmlsec/transforms.h:953,
>  from C:/gcdev64/gnucash/unstable/
> src/xmlsec-xmlsec-1_2_20/include/xmlsec/keyinfo.h:27,
>  from C:/gcdev64/gnucash/unstable/
> src/xmlsec-xmlsec-1_2_20/src/openssl/x509vfy.c:31:
> C:/gcdev64/gnucash/unstable/src/xmlsec-xmlsec-1_2_20/src/openssl/x509vfy.c:100:8:
> error: expected identifier or '(' before 'LPCSTR'
>  static X509_NAME*   xmlSecOpenSSLX509NameRead
> (xmlSecByte *str,
> ^
>
> Spent some time poking around but my knowledge is lacking. I did try a
> newer version of xmlsec but that fails in the same place and I also was
> wondering if the i686-w64-mingw32 included header files had changed as they
> are all new.
>
> Can any one point me in the right direction and also the build server has
> not done a successful run recently.
>
> Regards,
>   Bob
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Windows build procedure

[Robert Fewell]

OK this is confusing to me, I have looked at the code with gdb but it seems
to fail with a function in libglib dll file.

Added some print statements to various bits of code and here is what I
found...

assistant-ab-initial.c line 264 calls AB_SetupDialog_new

aqbanking\dialogs\dlg_setup.c line 56 calls GWEN_Dialog_new("ab_setup")

gwen\src\gui\dialog.c line 73 calls GWEN_Gui_ReadDialogPrefs(dialogId,
NULL, )

gwen\src\gui\gui.c line 1455 calls AB_Gui_ReadDialogPrefs

this returns 0 to GWEN_Gui_ReadDialogPrefs

GWEN_Gui_ReadDialogPrefs fails to return 0 to GWEN_Dialog_new and hence
application crashes

If you comment out GWEN_Gui_ReadDialogPrefs so it returns
GWEN_ERROR_NOT_IMPLEMENTED, the setup gui shows but application crashes
when you close it.

Bob


On 18 October 2017 at 15:53, Robert Fewell <14ubo...@gmail.com> wrote:

> Will have a look...
> Bob
>
> On 17 October 2017 at 17:28, John Ralls  wrote:
>
>> Bob,
>>
>> Thanks, I used this as a checklist.
>>
>> I've sorted out all of the problems but there's a new one to work on:
>> Clicking the Start AQBanking Wizard crashes. It doesn't look from the
>> backtrace like it's even getting that far... and it works fine on Mac and
>> Linux.
>>
>> Regards,
>> John Ralls
>>
>> > On Oct 13, 2017, at 5:16 AM, Robert Fewell <14ubo...@gmail.com> wrote:
>> >
>> > OK,
>> > I copied the gschema files from msys2\mingw32\share\glib-2.0\schemas
>> to a temp directory along with unstable\inst\share\glib-2.0\schemas
>> files and then ran glib-compile-schemas on this directory to create a new
>> gschemas.compiled file and then copied all the files in the directory to
>> 'c:\Program Files (x86)\gnucash\share\glib-2.0\schemas' which has solved
>> the Glib error and the file chooser now works.
>> >
>> > The icon error can be fixed by copying the
>> unstable\inst\share\icons\hicolor folder to either 'c:\Program Files
>> (86)\gnucash\share\gnucash\icons\hicolor' or c:\Program Files
>> (86)\gnucash\share\icons\hicolor', probably the later is the correct
>> location.
>> >
>> > I can not see what else is wrong with the aqbanking dll.
>> >
>> > Regards,
>> > Bob
>> >
>> > On 12 October 2017 at 17:48, Geert Janssens 
>> wrote:
>> >
>> >
>> > Robert Fewell <14ubo...@gmail.com> schreef op 12 oktober 2017 17:24:30
>> GMT+01:00:
>> > >John,
>> > >Now built unstable and created exe and installed, side note
>> > >bundle-mingw64.ps1 needs changing on line 134 to use 'GNC_VCS_REV'
>> > >
>> > >Still have the same problems, used dll walker on
>> > >libgncmod-aqbanking.dll
>> > >and it was missing libgwengui-gtk3.dll, copied that from the
>> > >unstable/build/bin directory to c:\gnucash\bin and that satisfied
>> > >the
>> > >dll walker. Started gnucash but still got the same error, maybe I
>> > >should of
>> > >walked on the libgwengui-gtk3.dll
>> > >
>> > >The preference error is to do with the gtk_file_chooser which may
>> > >relate to
>> > >the last error below, you also get the same thing by trying file/open
>> >
>> > (Snip)
>> >
>> > >* 16:00:14 OTHER  Settings schema
>> > >'org.gtk.Settings.FileChooser'
>> > >is not installed
>> > >
>> >
>> > A missing gsettings schema will indeed crash the application, or more
>> precisely it will abort it. Same effect to the user... This is a deliberate
>> design decision of the GSettings folks. Their reasoning being that an
>> application is supposed to know its schema so a missing one is considered a
>> fatal error.
>> >
>> > Geert
>> > >
>> > >Regards,
>> > >Bob
>> > >
>> > >
>> > >On 12 October 2017 at 01:37, John Ralls  wrote:
>> > >
>> > >>
>> > >>
>> > >> > On Oct 11, 2017, at 9:00 AM, Robert Fewell <14ubo...@gmail.com>
>> > >wrote:
>> > >> >
>> > >> > Thanks John, that is what I was after but did not realise I had
>> > >built
>> > >> master so made the appropriate changes, exe created and used for an
>> > >install.
>> > >> >
>> > >> > Noticed some dialogues pop up behind the main application and the
>> > >> preferences dialogue crashes the app. Also I am getting this in the
>> > >trace
>> > >> file...
>> > >> > * 15:01:28  WARN  Failed to dlopen() 'C:\Program Files
>> > >> (x86)\gnucash\bin\libgncmod-aqbanking.dll': 'C:\Program Files
>> > >> (x86)\gnucash\bin\libgncmod-aqbanking.dll': The specified module
>> > >could
>> > >> not be found.
>> > >> >
>> > >> > The file is there so not sure what is wrong with that, Will
>> > >probably try
>> > >> and build 'unstable' with debugging to see why the preferences crash
>> > >> tomorrow.
>> > >>
>> > >> Bob,
>> > >>
>> > >> Dlopen says “image not found” when it can’t find the shared module
>> > >it’s
>> > >> trying to load and “module not found” when it can’t find one of the
>> > >shared
>> > >> module’s dependencies.
>> > >>
>> > >> The least painful way to figure out missing dependencies on Windows
>> > >is a
>> > >> program called Dependency Walker, a free download from Microsoft.
>> > >>
>> > >> Regards,
>> > >> John Ralls
>> > 

Re: Windows build procedure

[Robert Fewell]

Will have a look...
Bob

On 17 October 2017 at 17:28, John Ralls  wrote:

> Bob,
>
> Thanks, I used this as a checklist.
>
> I've sorted out all of the problems but there's a new one to work on:
> Clicking the Start AQBanking Wizard crashes. It doesn't look from the
> backtrace like it's even getting that far... and it works fine on Mac and
> Linux.
>
> Regards,
> John Ralls
>
> > On Oct 13, 2017, at 5:16 AM, Robert Fewell <14ubo...@gmail.com> wrote:
> >
> > OK,
> > I copied the gschema files from msys2\mingw32\share\glib-2.0\schemas to
> a temp directory along with unstable\inst\share\glib-2.0\schemas files
> and then ran glib-compile-schemas on this directory to create a new
> gschemas.compiled file and then copied all the files in the directory to
> 'c:\Program Files (x86)\gnucash\share\glib-2.0\schemas' which has solved
> the Glib error and the file chooser now works.
> >
> > The icon error can be fixed by copying the unstable\inst\share\icons\hicolor
> folder to either 'c:\Program Files (86)\gnucash\share\gnucash\icons\hicolor'
> or c:\Program Files (86)\gnucash\share\icons\hicolor', probably the later
> is the correct location.
> >
> > I can not see what else is wrong with the aqbanking dll.
> >
> > Regards,
> > Bob
> >
> > On 12 October 2017 at 17:48, Geert Janssens 
> wrote:
> >
> >
> > Robert Fewell <14ubo...@gmail.com> schreef op 12 oktober 2017 17:24:30
> GMT+01:00:
> > >John,
> > >Now built unstable and created exe and installed, side note
> > >bundle-mingw64.ps1 needs changing on line 134 to use 'GNC_VCS_REV'
> > >
> > >Still have the same problems, used dll walker on
> > >libgncmod-aqbanking.dll
> > >and it was missing libgwengui-gtk3.dll, copied that from the
> > >unstable/build/bin directory to c:\gnucash\bin and that satisfied
> > >the
> > >dll walker. Started gnucash but still got the same error, maybe I
> > >should of
> > >walked on the libgwengui-gtk3.dll
> > >
> > >The preference error is to do with the gtk_file_chooser which may
> > >relate to
> > >the last error below, you also get the same thing by trying file/open
> >
> > (Snip)
> >
> > >* 16:00:14 OTHER  Settings schema
> > >'org.gtk.Settings.FileChooser'
> > >is not installed
> > >
> >
> > A missing gsettings schema will indeed crash the application, or more
> precisely it will abort it. Same effect to the user... This is a deliberate
> design decision of the GSettings folks. Their reasoning being that an
> application is supposed to know its schema so a missing one is considered a
> fatal error.
> >
> > Geert
> > >
> > >Regards,
> > >Bob
> > >
> > >
> > >On 12 October 2017 at 01:37, John Ralls  wrote:
> > >
> > >>
> > >>
> > >> > On Oct 11, 2017, at 9:00 AM, Robert Fewell <14ubo...@gmail.com>
> > >wrote:
> > >> >
> > >> > Thanks John, that is what I was after but did not realise I had
> > >built
> > >> master so made the appropriate changes, exe created and used for an
> > >install.
> > >> >
> > >> > Noticed some dialogues pop up behind the main application and the
> > >> preferences dialogue crashes the app. Also I am getting this in the
> > >trace
> > >> file...
> > >> > * 15:01:28  WARN  Failed to dlopen() 'C:\Program Files
> > >> (x86)\gnucash\bin\libgncmod-aqbanking.dll': 'C:\Program Files
> > >> (x86)\gnucash\bin\libgncmod-aqbanking.dll': The specified module
> > >could
> > >> not be found.
> > >> >
> > >> > The file is there so not sure what is wrong with that, Will
> > >probably try
> > >> and build 'unstable' with debugging to see why the preferences crash
> > >> tomorrow.
> > >>
> > >> Bob,
> > >>
> > >> Dlopen says “image not found” when it can’t find the shared module
> > >it’s
> > >> trying to load and “module not found” when it can’t find one of the
> > >shared
> > >> module’s dependencies.
> > >>
> > >> The least painful way to figure out missing dependencies on Windows
> > >is a
> > >> program called Dependency Walker, a free download from Microsoft.
> > >>
> > >> Regards,
> > >> John Ralls
> > >___
> > >gnucash-devel mailing list
> > >gnucash-devel@gnucash.org
> > >https://lists.gnucash.org/mailman/listinfo/gnucash-devel
> >
> > Sent from my smartphone. Please excuse my brevity.
> >
>
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Windows build procedure

[John Ralls]

Bob,

Thanks, I used this as a checklist.

I've sorted out all of the problems but there's a new one to work on: Clicking 
the Start AQBanking Wizard crashes. It doesn't look from the backtrace like 
it's even getting that far... and it works fine on Mac and Linux.

Regards,
John Ralls

> On Oct 13, 2017, at 5:16 AM, Robert Fewell <14ubo...@gmail.com> wrote:
> 
> OK,
> I copied the gschema files from msys2\mingw32\share\glib-2.0\schemas to a 
> temp directory along with unstable\inst\share\glib-2.0\schemas files and then 
> ran glib-compile-schemas on this directory to create a new gschemas.compiled 
> file and then copied all the files in the directory to 'c:\Program Files 
> (x86)\gnucash\share\glib-2.0\schemas' which has solved the Glib error and the 
> file chooser now works.
> 
> The icon error can be fixed by copying the unstable\inst\share\icons\hicolor 
> folder to either 'c:\Program Files (86)\gnucash\share\gnucash\icons\hicolor' 
> or c:\Program Files (86)\gnucash\share\icons\hicolor', probably the later is 
> the correct location.
> 
> I can not see what else is wrong with the aqbanking dll.
> 
> Regards,
> Bob 
> 
> On 12 October 2017 at 17:48, Geert Janssens  
> wrote:
> 
> 
> Robert Fewell <14ubo...@gmail.com> schreef op 12 oktober 2017 17:24:30 
> GMT+01:00:
> >John,
> >Now built unstable and created exe and installed, side note
> >bundle-mingw64.ps1 needs changing on line 134 to use 'GNC_VCS_REV'
> >
> >Still have the same problems, used dll walker on
> >libgncmod-aqbanking.dll
> >and it was missing libgwengui-gtk3.dll, copied that from the
> >unstable/build/bin directory to c:\gnucash\bin and that satisfied
> >the
> >dll walker. Started gnucash but still got the same error, maybe I
> >should of
> >walked on the libgwengui-gtk3.dll
> >
> >The preference error is to do with the gtk_file_chooser which may
> >relate to
> >the last error below, you also get the same thing by trying file/open
> 
> (Snip)
> 
> >* 16:00:14 OTHER  Settings schema
> >'org.gtk.Settings.FileChooser'
> >is not installed
> >
> 
> A missing gsettings schema will indeed crash the application, or more 
> precisely it will abort it. Same effect to the user... This is a deliberate 
> design decision of the GSettings folks. Their reasoning being that an 
> application is supposed to know its schema so a missing one is considered a 
> fatal error.
> 
> Geert
> >
> >Regards,
> >Bob
> >
> >
> >On 12 October 2017 at 01:37, John Ralls  wrote:
> >
> >>
> >>
> >> > On Oct 11, 2017, at 9:00 AM, Robert Fewell <14ubo...@gmail.com>
> >wrote:
> >> >
> >> > Thanks John, that is what I was after but did not realise I had
> >built
> >> master so made the appropriate changes, exe created and used for an
> >install.
> >> >
> >> > Noticed some dialogues pop up behind the main application and the
> >> preferences dialogue crashes the app. Also I am getting this in the
> >trace
> >> file...
> >> > * 15:01:28  WARN  Failed to dlopen() 'C:\Program Files
> >> (x86)\gnucash\bin\libgncmod-aqbanking.dll': 'C:\Program Files
> >> (x86)\gnucash\bin\libgncmod-aqbanking.dll': The specified module
> >could
> >> not be found.
> >> >
> >> > The file is there so not sure what is wrong with that, Will
> >probably try
> >> and build 'unstable' with debugging to see why the preferences crash
> >> tomorrow.
> >>
> >> Bob,
> >>
> >> Dlopen says “image not found” when it can’t find the shared module
> >it’s
> >> trying to load and “module not found” when it can’t find one of the
> >shared
> >> module’s dependencies.
> >>
> >> The least painful way to figure out missing dependencies on Windows
> >is a
> >> program called Dependency Walker, a free download from Microsoft.
> >>
> >> Regards,
> >> John Ralls
> >___
> >gnucash-devel mailing list
> >gnucash-devel@gnucash.org
> >https://lists.gnucash.org/mailman/listinfo/gnucash-devel
> 
> Sent from my smartphone. Please excuse my brevity.
> 

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Windows build procedure

[Robert Fewell]

OK,
I copied the gschema files from msys2\mingw32\share\glib-2.0\schemas to a
temp directory along with unstable\inst\share\glib-2.0\schemas files and
then ran glib-compile-schemas on this directory to create a new
gschemas.compiled file and then copied all the files in the directory to
'c:\Program Files (x86)\gnucash\share\glib-2.0\schemas' which has solved
the Glib error and the file chooser now works.

The icon error can be fixed by copying the
unstable\inst\share\icons\hicolor folder to either 'c:\Program Files
(86)\gnucash\share\gnucash\icons\hicolor' or c:\Program Files
(86)\gnucash\share\icons\hicolor', probably the later is the correct
location.

I can not see what else is wrong with the aqbanking dll.

Regards,
Bob

On 12 October 2017 at 17:48, Geert Janssens 
wrote:

>
>
> Robert Fewell <14ubo...@gmail.com> schreef op 12 oktober 2017 17:24:30
> GMT+01:00:
> >John,
> >Now built unstable and created exe and installed, side note
> >bundle-mingw64.ps1 needs changing on line 134 to use 'GNC_VCS_REV'
> >
> >Still have the same problems, used dll walker on
> >libgncmod-aqbanking.dll
> >and it was missing libgwengui-gtk3.dll, copied that from the
> >unstable/build/bin directory to c:\gnucash\bin and that satisfied
> >the
> >dll walker. Started gnucash but still got the same error, maybe I
> >should of
> >walked on the libgwengui-gtk3.dll
> >
> >The preference error is to do with the gtk_file_chooser which may
> >relate to
> >the last error below, you also get the same thing by trying file/open
>
> (Snip)
>
> >* 16:00:14 OTHER  Settings schema
> >'org.gtk.Settings.FileChooser'
> >is not installed
> >
>
> A missing gsettings schema will indeed crash the application, or more
> precisely it will abort it. Same effect to the user... This is a deliberate
> design decision of the GSettings folks. Their reasoning being that an
> application is supposed to know its schema so a missing one is considered a
> fatal error.
>
> Geert
> >
> >Regards,
> >Bob
> >
> >
> >On 12 October 2017 at 01:37, John Ralls  wrote:
> >
> >>
> >>
> >> > On Oct 11, 2017, at 9:00 AM, Robert Fewell <14ubo...@gmail.com>
> >wrote:
> >> >
> >> > Thanks John, that is what I was after but did not realise I had
> >built
> >> master so made the appropriate changes, exe created and used for an
> >install.
> >> >
> >> > Noticed some dialogues pop up behind the main application and the
> >> preferences dialogue crashes the app. Also I am getting this in the
> >trace
> >> file...
> >> > * 15:01:28  WARN  Failed to dlopen() 'C:\Program Files
> >> (x86)\gnucash\bin\libgncmod-aqbanking.dll': 'C:\Program Files
> >> (x86)\gnucash\bin\libgncmod-aqbanking.dll': The specified module
> >could
> >> not be found.
> >> >
> >> > The file is there so not sure what is wrong with that, Will
> >probably try
> >> and build 'unstable' with debugging to see why the preferences crash
> >> tomorrow.
> >>
> >> Bob,
> >>
> >> Dlopen says “image not found” when it can’t find the shared module
> >it’s
> >> trying to load and “module not found” when it can’t find one of the
> >shared
> >> module’s dependencies.
> >>
> >> The least painful way to figure out missing dependencies on Windows
> >is a
> >> program called Dependency Walker, a free download from Microsoft.
> >>
> >> Regards,
> >> John Ralls
> >___
> >gnucash-devel mailing list
> >gnucash-devel@gnucash.org
> >https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>
> Sent from my smartphone. Please excuse my brevity.
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Windows build procedure

[Geert Janssens]

Robert Fewell <14ubo...@gmail.com> schreef op 12 oktober 2017 17:24:30 
GMT+01:00:
>John,
>Now built unstable and created exe and installed, side note
>bundle-mingw64.ps1 needs changing on line 134 to use 'GNC_VCS_REV'
>
>Still have the same problems, used dll walker on
>libgncmod-aqbanking.dll
>and it was missing libgwengui-gtk3.dll, copied that from the
>unstable/build/bin directory to c:\gnucash\bin and that satisfied
>the
>dll walker. Started gnucash but still got the same error, maybe I
>should of
>walked on the libgwengui-gtk3.dll
>
>The preference error is to do with the gtk_file_chooser which may
>relate to
>the last error below, you also get the same thing by trying file/open

(Snip)

>* 16:00:14 OTHER  Settings schema
>'org.gtk.Settings.FileChooser'
>is not installed
>

A missing gsettings schema will indeed crash the application, or more precisely 
it will abort it. Same effect to the user... This is a deliberate design 
decision of the GSettings folks. Their reasoning being that an application is 
supposed to know its schema so a missing one is considered a fatal error.

Geert
>
>Regards,
>Bob
>
>
>On 12 October 2017 at 01:37, John Ralls  wrote:
>
>>
>>
>> > On Oct 11, 2017, at 9:00 AM, Robert Fewell <14ubo...@gmail.com>
>wrote:
>> >
>> > Thanks John, that is what I was after but did not realise I had
>built
>> master so made the appropriate changes, exe created and used for an
>install.
>> >
>> > Noticed some dialogues pop up behind the main application and the
>> preferences dialogue crashes the app. Also I am getting this in the
>trace
>> file...
>> > * 15:01:28  WARN  Failed to dlopen() 'C:\Program Files
>> (x86)\gnucash\bin\libgncmod-aqbanking.dll': 'C:\Program Files
>> (x86)\gnucash\bin\libgncmod-aqbanking.dll': The specified module
>could
>> not be found.
>> >
>> > The file is there so not sure what is wrong with that, Will
>probably try
>> and build 'unstable' with debugging to see why the preferences crash
>> tomorrow.
>>
>> Bob,
>>
>> Dlopen says “image not found” when it can’t find the shared module
>it’s
>> trying to load and “module not found” when it can’t find one of the
>shared
>> module’s dependencies.
>>
>> The least painful way to figure out missing dependencies on Windows
>is a
>> program called Dependency Walker, a free download from Microsoft.
>>
>> Regards,
>> John Ralls
>___
>gnucash-devel mailing list
>gnucash-devel@gnucash.org
>https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Sent from my smartphone. Please excuse my brevity.
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Windows build procedure

[Robert Fewell]

John,
Now built unstable and created exe and installed, side note
bundle-mingw64.ps1 needs changing on line 134 to use 'GNC_VCS_REV'

Still have the same problems, used dll walker on libgncmod-aqbanking.dll
and it was missing libgwengui-gtk3.dll, copied that from the
unstable/build/bin directory to c:\gnucash\bin and that satisfied the
dll walker. Started gnucash but still got the same error, maybe I should of
walked on the libgwengui-gtk3.dll

The preference error is to do with the gtk_file_chooser which may relate to
the last error below, you also get the same thing by trying file/open

Will look at the missing icon later.

Full Trace file below...
* 15:59:50  WARN  Failed to dlopen() 'C:\Program Files
(x86)\gnucash\bin\libgncmod-aqbanking.dll': 'C:\Program Files
(x86)\gnucash\bin\libgncmod-aqbanking.dll': The specified module could not
be found.
* 15:59:50  WARN  [gnc_load_app_icons()] No icon named
'gnucash-icon' found. Some gui elements may be missing their icons
* 16:00:06  WARN  Could not spawn perl: Failed to execute
helper program (Invalid argument)
* 16:00:14 OTHER  Settings schema 'org.gtk.Settings.FileChooser'
is not installed


Regards,
Bob


On 12 October 2017 at 01:37, John Ralls  wrote:

>
>
> > On Oct 11, 2017, at 9:00 AM, Robert Fewell <14ubo...@gmail.com> wrote:
> >
> > Thanks John, that is what I was after but did not realise I had built
> master so made the appropriate changes, exe created and used for an install.
> >
> > Noticed some dialogues pop up behind the main application and the
> preferences dialogue crashes the app. Also I am getting this in the trace
> file...
> > * 15:01:28  WARN  Failed to dlopen() 'C:\Program Files
> (x86)\gnucash\bin\libgncmod-aqbanking.dll': 'C:\Program Files
> (x86)\gnucash\bin\libgncmod-aqbanking.dll': The specified module could
> not be found.
> >
> > The file is there so not sure what is wrong with that, Will probably try
> and build 'unstable' with debugging to see why the preferences crash
> tomorrow.
>
> Bob,
>
> Dlopen says “image not found” when it can’t find the shared module it’s
> trying to load and “module not found” when it can’t find one of the shared
> module’s dependencies.
>
> The least painful way to figure out missing dependencies on Windows is a
> program called Dependency Walker, a free download from Microsoft.
>
> Regards,
> John Ralls
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Windows build procedure

[John Ralls]

> On Oct 11, 2017, at 9:00 AM, Robert Fewell <14ubo...@gmail.com> wrote:
> 
> Thanks John, that is what I was after but did not realise I had built master 
> so made the appropriate changes, exe created and used for an install.
> 
> Noticed some dialogues pop up behind the main application and the preferences 
> dialogue crashes the app. Also I am getting this in the trace file...
> * 15:01:28  WARN  Failed to dlopen() 'C:\Program Files 
> (x86)\gnucash\bin\libgncmod-aqbanking.dll': 'C:\Program Files 
> (x86)\gnucash\bin\libgncmod-aqbanking.dll': The specified module could not be 
> found.
> 
> The file is there so not sure what is wrong with that, Will probably try and 
> build 'unstable' with debugging to see why the preferences crash tomorrow.

Bob,

Dlopen says “image not found” when it can’t find the shared module it’s trying 
to load and “module not found” when it can’t find one of the shared module’s 
dependencies.

The least painful way to figure out missing dependencies on Windows is a 
program called Dependency Walker, a free download from Microsoft.

Regards,
John Ralls
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Windows build procedure

[Robert Fewell]

Thanks John, that is what I was after but did not realise I had built
master so made the appropriate changes, exe created and used for an install.

Noticed some dialogues pop up behind the main application and the
preferences dialogue crashes the app. Also I am getting this in the trace
file...
* 15:01:28  WARN  Failed to dlopen() 'C:\Program Files
(x86)\gnucash\bin\libgncmod-aqbanking.dll': 'C:\Program Files
(x86)\gnucash\bin\libgncmod-aqbanking.dll': The specified module could not
be found.

The file is there so not sure what is wrong with that, Will probably try
and build 'unstable' with debugging to see why the preferences crash
tomorrow.

Regards,
Bob

On 11 October 2017 at 14:51, John Ralls  wrote:

>
>
> > On Oct 11, 2017, at 3:27 AM, Robert Fewell <14ubo...@gmail.com> wrote:
> >
> > Hi,
> > What is the current way to build the unstable/master install package on
> > Windows 10, I am almost there but missing a step I think, what I have
> done
> > is...
> >
> > Got the gnucash-on-windows from git
> > ran setup-mingw64.ps1 which completed successfully
> > ran the jhbuild which built 17 parts
> >
> > this is where I am stuck, I can start gnucash using the
> > gnucash-launcher.cmd if I add 'set
> > PATH=C:/gcdev64/msys2/mingw32/bin;%PATH%' but with missing gtk icons but
> > that was easily fixed by copying an icons folder to share\icons
> >
> > I see there is bundle-ming64.ps1, should this be the next step, what
> > parameters should be used ?
> >
>
> Bob,
>
> If you’re trying to make gnucash-foo-setup.exe then yes,
> bundle-mingw64.ps1 is the way to do it. If you took the default root dir
> (c:\gcdev64) and built unstable you’d invoke it with:
>
> bundle-mingw64.ps1 -root_dir c:\gcdev64 -target_dir
> c:\gcdev64\gnucash\unstable -project gnucash -git_build $true
>
> Regards,
> John Ralls
>
>
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Windows build procedure

[John Ralls]

> On Oct 11, 2017, at 3:27 AM, Robert Fewell <14ubo...@gmail.com> wrote:
> 
> Hi,
> What is the current way to build the unstable/master install package on
> Windows 10, I am almost there but missing a step I think, what I have done
> is...
> 
> Got the gnucash-on-windows from git
> ran setup-mingw64.ps1 which completed successfully
> ran the jhbuild which built 17 parts
> 
> this is where I am stuck, I can start gnucash using the
> gnucash-launcher.cmd if I add 'set
> PATH=C:/gcdev64/msys2/mingw32/bin;%PATH%' but with missing gtk icons but
> that was easily fixed by copying an icons folder to share\icons
> 
> I see there is bundle-ming64.ps1, should this be the next step, what
> parameters should be used ?
> 

Bob,

If you’re trying to make gnucash-foo-setup.exe then yes, bundle-mingw64.ps1 is 
the way to do it. If you took the default root dir (c:\gcdev64) and built 
unstable you’d invoke it with:

bundle-mingw64.ps1 -root_dir c:\gcdev64 -target_dir c:\gcdev64\gnucash\unstable 
-project gnucash -git_build $true

Regards,
John Ralls


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Windows Build failure

[Robert Fewell]

John,

Have built from scratch and confirm Gnucash starts OK from creating a dist
file.


Not sure if this is related or just a coincidence, but if I try and start
from the inst/bin/gnucash-launcher.cmd I get the following error...

'The procedure __gmpn_cnd_add_n can not be found in libgmp-10.dll'

Doing a search for that dll file I find two copies, one in gcdev\mingw\bin
and one in gcdev\gnutls\bin which are different.

To fix the problem, I swapped the two lines that add the directories above
to generate the path in the cmd file.

Regards,
Robert



On 28 July 2015 at 17:19, John Ralls jra...@ceridwen.us wrote:


  On Jul 27, 2015, at 12:59 PM, John Ralls jra...@ceridwen.us wrote:
 
 
  On Jul 27, 2015, at 10:21 AM, Robert Fewell 14ubo...@gmail.com wrote:
 
  John,
 
  I have given it a try and it partially fixes the problem. Gnucash now
 builds OK but it still failed on startup. Just to make sure I created a
 setup.exe from the dist script and installed that which failed initially
 because it could not find the lib_boost_date.dll, these were in the lib
 directory but when I moved them to the bin directory Gnucash found the
 files and failed the same as from the build directory.
 
  Just to make sure it was not my XP build VM, I used the setup.exe on
 another XP VM and when I had moved the boost dll files, it started up just
 fine.
 
  Comparing the two, the one that worked had Time Zone 'GMT London' with
 DST ticked and the one that fails has 'GMT Monrovia/Reykjavik', swapping
 between the two allows it to run or fail.
 
 
  Darn. I knew about putting the libs in the wrong place but forgot to
 commit the fix. Done now.
 
  Ah, Liberia and Iceland are places that have the good sense not to use
 daylight time so the registry entry has 0 values for the transition times,
 and I’m not handling that correctly on Win32. Should be a straightforward
 fix.


 Robert,

 I just tested today’s nightly build in XP with the TZ set for
 Monrovia/Reykjavic and it started up without errors.

 Regards,
 John Ralls


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Windows Build failure

[John Ralls]

 On Jul 27, 2015, at 12:59 PM, John Ralls jra...@ceridwen.us wrote:
 
 
 On Jul 27, 2015, at 10:21 AM, Robert Fewell 14ubo...@gmail.com wrote:
 
 John,
 
 I have given it a try and it partially fixes the problem. Gnucash now builds 
 OK but it still failed on startup. Just to make sure I created a setup.exe 
 from the dist script and installed that which failed initially because it 
 could not find the lib_boost_date.dll, these were in the lib directory but 
 when I moved them to the bin directory Gnucash found the files and failed 
 the same as from the build directory.
 
 Just to make sure it was not my XP build VM, I used the setup.exe on another 
 XP VM and when I had moved the boost dll files, it started up just fine.
 
 Comparing the two, the one that worked had Time Zone 'GMT London' with DST 
 ticked and the one that fails has 'GMT Monrovia/Reykjavik', swapping between 
 the two allows it to run or fail.
 
 
 Darn. I knew about putting the libs in the wrong place but forgot to commit 
 the fix. Done now.
 
 Ah, Liberia and Iceland are places that have the good sense not to use 
 daylight time so the registry entry has 0 values for the transition times, 
 and I’m not handling that correctly on Win32. Should be a straightforward fix.


Robert,

I just tested today’s nightly build in XP with the TZ set for 
Monrovia/Reykjavic and it started up without errors.

Regards,
John Ralls


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Windows Build failure

[Robert Fewell]

John,

I have given it a try and it partially fixes the problem. Gnucash now
builds OK but it still failed on startup. Just to make sure I created a
setup.exe from the dist script and installed that which failed initially
because it could not find the lib_boost_date.dll, these were in the lib
directory but when I moved them to the bin directory Gnucash found the
files and failed the same as from the build directory.

Just to make sure it was not my XP build VM, I used the setup.exe on
another XP VM and when I had moved the boost dll files, it started up just
fine.

Comparing the two, the one that worked had Time Zone 'GMT London' with DST
ticked and the one that fails has 'GMT Monrovia/Reykjavik', swapping
between the two allows it to run or fail.


Regards,
Robert

On 25 July 2015 at 19:25, John Ralls jra...@ceridwen.us wrote:


  On Jul 25, 2015, at 7:19 AM, John Ralls jra...@ceridwen.us wrote:
 
 
  On Jul 25, 2015, at 2:55 AM, Robert Fewell 14ubo...@gmail.com wrote:
 
  John,
 
  Still no luck with your revised patch. There is no codecvt header file
 but I did find one in bits/codecvt.h, tried adding that instead but still
 failed, looked in that file and seemed to imply it should not be used
 directly and maybe locale is the way to go.
  Tried that and get the following error...
 
  c:/gcdev/gnucash.git/src/libqof/qof/gnc-timezone.cpp: In member
 function 'void TimeZoneProvider::load_windows_default_tz
  ()':
  c:/gcdev/gnucash.git/src/libqof/qof/gnc-timezone.cpp:241:5: error:
 'wstring_convert' is not a member of 'std'
  std::wstring_convertstd::codecvt_utf8_utf16char16_t,char16_t
 conversion;
  ^
  c:/gcdev/gnucash.git/src/libqof/qof/gnc-timezone.cpp:241:26: error:
 'codecvt_utf8_utf16' is not a member of 'std'
  std::wstring_convertstd::codecvt_utf8_utf16char16_t,char16_t
 conversion;
   ^
  c:/gcdev/gnucash.git/src/libqof/qof/gnc-timezone.cpp:241:50: error:
 expected primary-expression before 'char16_t'
  std::wstring_convertstd::codecvt_utf8_utf16char16_t,char16_t
 conversion;
   ^
  c:/gcdev/gnucash.git/src/libqof/qof/gnc-timezone.cpp:241:50: error:
 expected ';' before 'char16_t'
  c:/gcdev/gnucash.git/src/libqof/qof/gnc-timezone.cpp:242:21: error:
 'conversion' was not declared in this scope
  auto std_name = conversion.to_bytes(tzi.StandardName);
  ^
  At global scope:
  cc1plus.exe: error: unrecognized command line option
 -Wno-deprecated-register [-Werror]
  cc1plus.exe: all warnings being treated as errors
 
  Attached are the changes I am currently using.
 
  Robert,
 
  I found that out too as soon as I got back and tested it yesterday
 afternoon. Boost::locale provides a similar service so I switched to that.
 There were a couple of other holes in my implementation, which I think I’ve
 resolved but ran out of time yesterday to test them. I expect I’ll have a
 fix pushed this afternoon.

 Robert,

 I just pushed a couple of commits which fix the timezone exception problem
 on my XP VM. Please test it and let me know if it works for you.

 Regards,
 John Ralls


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Windows Build failure

[John Ralls]

 On Jul 27, 2015, at 10:21 AM, Robert Fewell 14ubo...@gmail.com wrote:
 
 John,
 
 I have given it a try and it partially fixes the problem. Gnucash now builds 
 OK but it still failed on startup. Just to make sure I created a setup.exe 
 from the dist script and installed that which failed initially because it 
 could not find the lib_boost_date.dll, these were in the lib directory but 
 when I moved them to the bin directory Gnucash found the files and failed the 
 same as from the build directory.
 
 Just to make sure it was not my XP build VM, I used the setup.exe on another 
 XP VM and when I had moved the boost dll files, it started up just fine.
 
 Comparing the two, the one that worked had Time Zone 'GMT London' with DST 
 ticked and the one that fails has 'GMT Monrovia/Reykjavik', swapping between 
 the two allows it to run or fail.
 

Darn. I knew about putting the libs in the wrong place but forgot to commit the 
fix. Done now.

Ah, Liberia and Iceland are places that have the good sense not to use daylight 
time so the registry entry has 0 values for the transition times, and I’m not 
handling that correctly on Win32. Should be a straightforward fix.

Regards,
John Ralls
 
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Windows Build failure

[John Ralls]

 On Jul 25, 2015, at 2:55 AM, Robert Fewell 14ubo...@gmail.com wrote:
 
 John,
 
 Still no luck with your revised patch. There is no codecvt header file but I 
 did find one in bits/codecvt.h, tried adding that instead but still failed, 
 looked in that file and seemed to imply it should not be used directly and 
 maybe locale is the way to go.
 Tried that and get the following error...
 
 c:/gcdev/gnucash.git/src/libqof/qof/gnc-timezone.cpp: In member function 
 'void TimeZoneProvider::load_windows_default_tz
 ()':
 c:/gcdev/gnucash.git/src/libqof/qof/gnc-timezone.cpp:241:5: error: 
 'wstring_convert' is not a member of 'std'
  std::wstring_convertstd::codecvt_utf8_utf16char16_t,char16_t 
 conversion;
  ^
 c:/gcdev/gnucash.git/src/libqof/qof/gnc-timezone.cpp:241:26: error: 
 'codecvt_utf8_utf16' is not a member of 'std'
  std::wstring_convertstd::codecvt_utf8_utf16char16_t,char16_t 
 conversion;
   ^
 c:/gcdev/gnucash.git/src/libqof/qof/gnc-timezone.cpp:241:50: error: expected 
 primary-expression before 'char16_t'
  std::wstring_convertstd::codecvt_utf8_utf16char16_t,char16_t 
 conversion;
   ^
 c:/gcdev/gnucash.git/src/libqof/qof/gnc-timezone.cpp:241:50: error: expected 
 ';' before 'char16_t'
 c:/gcdev/gnucash.git/src/libqof/qof/gnc-timezone.cpp:242:21: error: 
 'conversion' was not declared in this scope
  auto std_name = conversion.to_bytes(tzi.StandardName);
  ^
 At global scope:
 cc1plus.exe: error: unrecognized command line option 
 -Wno-deprecated-register [-Werror]
 cc1plus.exe: all warnings being treated as errors
 
 Attached are the changes I am currently using.

Robert,

I found that out too as soon as I got back and tested it yesterday afternoon. 
Boost::locale provides a similar service so I switched to that. There were a 
couple of other holes in my implementation, which I think I’ve resolved but ran 
out of time yesterday to test them. I expect I’ll have a fix pushed this 
afternoon.

Regards,
John Ralls


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Windows Build failure

[John Ralls]

 On Jul 25, 2015, at 7:19 AM, John Ralls jra...@ceridwen.us wrote:
 
 
 On Jul 25, 2015, at 2:55 AM, Robert Fewell 14ubo...@gmail.com wrote:
 
 John,
 
 Still no luck with your revised patch. There is no codecvt header file but I 
 did find one in bits/codecvt.h, tried adding that instead but still failed, 
 looked in that file and seemed to imply it should not be used directly and 
 maybe locale is the way to go.
 Tried that and get the following error...
 
 c:/gcdev/gnucash.git/src/libqof/qof/gnc-timezone.cpp: In member function 
 'void TimeZoneProvider::load_windows_default_tz
 ()':
 c:/gcdev/gnucash.git/src/libqof/qof/gnc-timezone.cpp:241:5: error: 
 'wstring_convert' is not a member of 'std'
 std::wstring_convertstd::codecvt_utf8_utf16char16_t,char16_t 
 conversion;
 ^
 c:/gcdev/gnucash.git/src/libqof/qof/gnc-timezone.cpp:241:26: error: 
 'codecvt_utf8_utf16' is not a member of 'std'
 std::wstring_convertstd::codecvt_utf8_utf16char16_t,char16_t 
 conversion;
  ^
 c:/gcdev/gnucash.git/src/libqof/qof/gnc-timezone.cpp:241:50: error: expected 
 primary-expression before 'char16_t'
 std::wstring_convertstd::codecvt_utf8_utf16char16_t,char16_t 
 conversion;
  ^
 c:/gcdev/gnucash.git/src/libqof/qof/gnc-timezone.cpp:241:50: error: expected 
 ';' before 'char16_t'
 c:/gcdev/gnucash.git/src/libqof/qof/gnc-timezone.cpp:242:21: error: 
 'conversion' was not declared in this scope
 auto std_name = conversion.to_bytes(tzi.StandardName);
 ^
 At global scope:
 cc1plus.exe: error: unrecognized command line option 
 -Wno-deprecated-register [-Werror]
 cc1plus.exe: all warnings being treated as errors
 
 Attached are the changes I am currently using.
 
 Robert,
 
 I found that out too as soon as I got back and tested it yesterday afternoon. 
 Boost::locale provides a similar service so I switched to that. There were a 
 couple of other holes in my implementation, which I think I’ve resolved but 
 ran out of time yesterday to test them. I expect I’ll have a fix pushed this 
 afternoon.

Robert,

I just pushed a couple of commits which fix the timezone exception problem on 
my XP VM. Please test it and let me know if it works for you.

Regards,
John Ralls


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Windows Build failure

[Robert Fewell]

John,

Still no luck with your revised patch. There is no codecvt header file but
I did find one in bits/codecvt.h, tried adding that instead but still
failed, looked in that file and seemed to imply it should not be used
directly and maybe locale is the way to go.
Tried that and get the following error...

c:/gcdev/gnucash.git/src/libqof/qof/gnc-timezone.cpp: In member function
'void TimeZoneProvider::load_windows_default_tz
()':
c:/gcdev/gnucash.git/src/libqof/qof/gnc-timezone.cpp:241:5: error:
'wstring_convert' is not a member of 'std'
 std::wstring_convertstd::codecvt_utf8_utf16char16_t,char16_t
conversion;
 ^
c:/gcdev/gnucash.git/src/libqof/qof/gnc-timezone.cpp:241:26: error:
'codecvt_utf8_utf16' is not a member of 'std'
 std::wstring_convertstd::codecvt_utf8_utf16char16_t,char16_t
conversion;
  ^
c:/gcdev/gnucash.git/src/libqof/qof/gnc-timezone.cpp:241:50: error:
expected primary-expression before 'char16_t'
 std::wstring_convertstd::codecvt_utf8_utf16char16_t,char16_t
conversion;
  ^
c:/gcdev/gnucash.git/src/libqof/qof/gnc-timezone.cpp:241:50: error:
expected ';' before 'char16_t'
c:/gcdev/gnucash.git/src/libqof/qof/gnc-timezone.cpp:242:21: error:
'conversion' was not declared in this scope
 auto std_name = conversion.to_bytes(tzi.StandardName);
 ^
At global scope:
cc1plus.exe: error: unrecognized command line option
-Wno-deprecated-register [-Werror]
cc1plus.exe: all warnings being treated as errors

Attached are the changes I am currently using.

Regards,

 Robert


On 24 July 2015 at 18:13, John Ralls jra...@ceridwen.us wrote:


  On Jul 24, 2015, at 6:09 AM, Robert Fewell 14ubo...@gmail.com wrote:
 
  John,
 
  Still trying to compile with your patch with the following changes for
 load_windows_default_tz...
 
  void
  TimeZoneProvider::load_windows_default_tz()
  {
  TIME_ZONE_INFORMATION tzi {};
  if (GetTimeZoneInformation (tzi) == TIME_ZONE_ID_INVALID)
  throw std::invalid_argument (No default time zone.);
  RegTZI regtzi { tzi.Bias, tzi.StandardBias, tzi.DaylightBias,
 tzi.StandardDate, tzi.DaylightDate };
 
  time_zone_names names (tzi.StandardName, tzi.StandardName,
 tzi.DaylightName, tzi.DaylightName);
 
  zone_vector.push_back(std::make_pair(0, zone_from_regtzi(regtzi,
 names)));
  }
 
  and I also added this to hpp file line 63...
 
  void load_windows_default_tz(void);
 
  but am getting this error...
 
  c:/gcdev/gnucash.git/src/libqof/qof/gnc-timezone.cpp: In member function
 'void TimeZoneProvider::load_windows_default_tz
  ()':
  c:/gcdev/gnucash.git/src/libqof/qof/gnc-timezone.cpp:237:98: error: no
 matching function for call to 'boost::date_time::
  time_zone_names_basechar::time_zone_names_base(WCHAR [32], WCHAR [32],
 WCHAR [32], WCHAR [32])'
   time_zone_names names (tzi.StandardName, tzi.StandardName,
 tzi.DaylightName, tzi.DaylightName);
 

^
  c:/gcdev/gnucash.git/src/libqof/qof/gnc-timezone.cpp:237:98: note:
 candidates are:
  In file included from
 c:/gcdev/boost/include/boost/date_time/local_time/custom_time_zone.hpp:12:0,
   from
 c:/gcdev/boost/include/boost/date_time/local_time/local_time_types.hpp:18,
   from
 c:/gcdev/boost/include/boost/date_time/local_time/local_time.hpp:13,
   from
 c:/gcdev/gnucash.git/src/libqof/qof/gnc-timezone.hpp:34,
   from
 c:/gcdev/gnucash.git/src/libqof/qof/gnc-timezone.cpp:23:
  c:/gcdev/boost/include/boost/date_time/time_zone_names.hpp:59:5: note:
 boost::date_time::time_zone_names_baseCharT::ti
  me_zone_names_base(const string_type, const string_type, const
 string_type, const string_type) [with CharT = char; b
  oost::date_time::time_zone_names_baseCharT::string_type =
 std::basic_stringchar]
   time_zone_names_base(const string_type std_zone_name_str,
   ^
  c:/gcdev/boost/include/boost/date_time/time_zone_names.hpp:59:5: note:
  no known conversion for argument 1 from 'WCHAR
  [32] {aka wchar_t [32]}' to 'const string_type {aka const
 std::basic_stringchar}'
  c:/gcdev/boost/include/boost/date_time/time_zone_names.hpp:53:5: note:
 boost::date_time::time_zone_names_baseCharT::ti
  me_zone_names_base() [with CharT = char]
   time_zone_names_base() :
   ^
  c:/gcdev/boost/include/boost/date_time/time_zone_names.hpp:53:5: note:
  candidate expects 0 arguments, 4 provided
  c:/gcdev/boost/include/boost/date_time/time_zone_names.hpp:49:9: note:
 boost::date_time::time_zone_names_basechar::tim
  e_zone_names_base(const boost::date_time::time_zone_names_basechar)
 class time_zone_names_base
  ^
  c:/gcdev/boost/include/boost/date_time/time_zone_names.hpp:49:9: note:
  candidate expects 1 argument, 4 provided
  c:/gcdev/boost/include/boost/date_time/time_zone_names.hpp:49:9: note:
 boost::date_time::time_zone_names_basechar::tim
  

Re: Windows Build failure

[Robert Fewell]

John,

Still trying to compile with your patch with the following changes for
load_windows_default_tz...

void
TimeZoneProvider::load_windows_default_tz()
{
TIME_ZONE_INFORMATION tzi {};
if (GetTimeZoneInformation (tzi) == TIME_ZONE_ID_INVALID)
throw std::invalid_argument (No default time zone.);
RegTZI regtzi { tzi.Bias, tzi.StandardBias, tzi.DaylightBias,
tzi.StandardDate, tzi.DaylightDate };

time_zone_names names (tzi.StandardName, tzi.StandardName,
tzi.DaylightName, tzi.DaylightName);

zone_vector.push_back(std::make_pair(0, zone_from_regtzi(regtzi,
names)));
}

and I also added this to hpp file line 63...

void load_windows_default_tz(void);

but am getting this error...

c:/gcdev/gnucash.git/src/libqof/qof/gnc-timezone.cpp: In member function
'void TimeZoneProvider::load_windows_default_tz
()':
c:/gcdev/gnucash.git/src/libqof/qof/gnc-timezone.cpp:237:98: error: no
matching function for call to 'boost::date_time::
time_zone_names_basechar::time_zone_names_base(WCHAR [32], WCHAR [32],
WCHAR [32], WCHAR [32])'
 time_zone_names names (tzi.StandardName, tzi.StandardName,
tzi.DaylightName, tzi.DaylightName);

 ^
c:/gcdev/gnucash.git/src/libqof/qof/gnc-timezone.cpp:237:98: note:
candidates are:
In file included from
c:/gcdev/boost/include/boost/date_time/local_time/custom_time_zone.hpp:12:0,
 from
c:/gcdev/boost/include/boost/date_time/local_time/local_time_types.hpp:18,
 from
c:/gcdev/boost/include/boost/date_time/local_time/local_time.hpp:13,
 from
c:/gcdev/gnucash.git/src/libqof/qof/gnc-timezone.hpp:34,
 from
c:/gcdev/gnucash.git/src/libqof/qof/gnc-timezone.cpp:23:
c:/gcdev/boost/include/boost/date_time/time_zone_names.hpp:59:5: note:
boost::date_time::time_zone_names_baseCharT::ti
me_zone_names_base(const string_type, const string_type, const
string_type, const string_type) [with CharT = char; b
oost::date_time::time_zone_names_baseCharT::string_type =
std::basic_stringchar]
 time_zone_names_base(const string_type std_zone_name_str,
 ^
c:/gcdev/boost/include/boost/date_time/time_zone_names.hpp:59:5: note:   no
known conversion for argument 1 from 'WCHAR
[32] {aka wchar_t [32]}' to 'const string_type {aka const
std::basic_stringchar}'
c:/gcdev/boost/include/boost/date_time/time_zone_names.hpp:53:5: note:
boost::date_time::time_zone_names_baseCharT::ti
me_zone_names_base() [with CharT = char]
 time_zone_names_base() :
 ^
c:/gcdev/boost/include/boost/date_time/time_zone_names.hpp:53:5: note:
candidate expects 0 arguments, 4 provided
c:/gcdev/boost/include/boost/date_time/time_zone_names.hpp:49:9: note:
boost::date_time::time_zone_names_basechar::tim
e_zone_names_base(const boost::date_time::time_zone_names_basechar)
   class time_zone_names_base
^
c:/gcdev/boost/include/boost/date_time/time_zone_names.hpp:49:9: note:
candidate expects 1 argument, 4 provided
c:/gcdev/boost/include/boost/date_time/time_zone_names.hpp:49:9: note:
boost::date_time::time_zone_names_basechar::tim
e_zone_names_base(boost::date_time::time_zone_names_basechar)
c:/gcdev/boost/include/boost/date_time/time_zone_names.hpp:49:9: note:
candidate expects 1 argument, 4 provided
At global scope:
cc1plus.exe: error: unrecognized command line option
-Wno-deprecated-register [-Werror]
cc1plus.exe: all warnings being treated as errors

Will ponder further but you may beat me to an answer.

Regards,

   Robert

On 24 July 2015 at 01:37, John Ralls jra...@ceridwen.us wrote:


  On Jul 21, 2015, at 9:18 AM, John Ralls jra...@ceridwen.us wrote:
 
 
  On Jul 21, 2015, at 3:28 AM, Robert Fewell 14ubo...@gmail.com wrote:
 
  John,
 
  I have found a better windows version of gdb and have set the break
 point and catch point as requested. Now running gnucash from gdb the
 exception stems from getting time zone information from
 gnc-timezone.cpp:240 as can be seen in attached image.
 
  Still trying to understand the c++ format but I think the registry keys
 are different in Windows XP to that of later versions as my XP does not
 have 'TimeZoneKeyName' used in windows_default_tzname.
 
 
  Robert,
 
  Hmm, the C version of that code in GLib and GC 2.4 doesn’t have a
 problem on XP, so I must have screwed something up when I ported it; it
 might just be throwing that exception, which is a bad idea since it can’t
 be caught in the way I’m using it. Since I can’t test on Windows until the
 weekend, if I can manage a patch before then I’ll send it to you to test.
 
  If you’re completely new to C++, Lipmann’s C++ Primer Plus is widely
 recommended.

 Robert,

 Here’s a first try at a patch. I can’t even test compile it until I get
 back tomorrow afternoon, but you can have a go at it and maybe fix any
 obvious typos.

 Regards,
 John Ralls


___
gnucash-devel mailing list
gnucash-devel@gnucash.org

Re: Windows Build failure

[John Ralls]

 On Jul 24, 2015, at 6:09 AM, Robert Fewell 14ubo...@gmail.com wrote:
 
 John,
 
 Still trying to compile with your patch with the following changes for 
 load_windows_default_tz...
 
 void
 TimeZoneProvider::load_windows_default_tz()
 {
 TIME_ZONE_INFORMATION tzi {};
 if (GetTimeZoneInformation (tzi) == TIME_ZONE_ID_INVALID)
 throw std::invalid_argument (No default time zone.);
 RegTZI regtzi { tzi.Bias, tzi.StandardBias, tzi.DaylightBias, 
 tzi.StandardDate, tzi.DaylightDate };
 
 time_zone_names names (tzi.StandardName, tzi.StandardName, 
 tzi.DaylightName, tzi.DaylightName);
 
 zone_vector.push_back(std::make_pair(0, zone_from_regtzi(regtzi, names)));
 }
 
 and I also added this to hpp file line 63...
 
 void load_windows_default_tz(void);
 
 but am getting this error...
 
 c:/gcdev/gnucash.git/src/libqof/qof/gnc-timezone.cpp: In member function 
 'void TimeZoneProvider::load_windows_default_tz
 ()':
 c:/gcdev/gnucash.git/src/libqof/qof/gnc-timezone.cpp:237:98: error: no 
 matching function for call to 'boost::date_time::
 time_zone_names_basechar::time_zone_names_base(WCHAR [32], WCHAR [32], 
 WCHAR [32], WCHAR [32])'
  time_zone_names names (tzi.StandardName, tzi.StandardName, 
 tzi.DaylightName, tzi.DaylightName);
   
   ^
 c:/gcdev/gnucash.git/src/libqof/qof/gnc-timezone.cpp:237:98: note: candidates 
 are:
 In file included from 
 c:/gcdev/boost/include/boost/date_time/local_time/custom_time_zone.hpp:12:0,
  from 
 c:/gcdev/boost/include/boost/date_time/local_time/local_time_types.hpp:18,
  from 
 c:/gcdev/boost/include/boost/date_time/local_time/local_time.hpp:13,
  from c:/gcdev/gnucash.git/src/libqof/qof/gnc-timezone.hpp:34,
  from c:/gcdev/gnucash.git/src/libqof/qof/gnc-timezone.cpp:23:
 c:/gcdev/boost/include/boost/date_time/time_zone_names.hpp:59:5: note: 
 boost::date_time::time_zone_names_baseCharT::ti
 me_zone_names_base(const string_type, const string_type, const 
 string_type, const string_type) [with CharT = char; b
 oost::date_time::time_zone_names_baseCharT::string_type = 
 std::basic_stringchar]
  time_zone_names_base(const string_type std_zone_name_str,
  ^
 c:/gcdev/boost/include/boost/date_time/time_zone_names.hpp:59:5: note:   no 
 known conversion for argument 1 from 'WCHAR
 [32] {aka wchar_t [32]}' to 'const string_type {aka const 
 std::basic_stringchar}'
 c:/gcdev/boost/include/boost/date_time/time_zone_names.hpp:53:5: note: 
 boost::date_time::time_zone_names_baseCharT::ti
 me_zone_names_base() [with CharT = char]
  time_zone_names_base() :
  ^
 c:/gcdev/boost/include/boost/date_time/time_zone_names.hpp:53:5: note:   
 candidate expects 0 arguments, 4 provided
 c:/gcdev/boost/include/boost/date_time/time_zone_names.hpp:49:9: note: 
 boost::date_time::time_zone_names_basechar::tim
 e_zone_names_base(const boost::date_time::time_zone_names_basechar)
class time_zone_names_base
 ^
 c:/gcdev/boost/include/boost/date_time/time_zone_names.hpp:49:9: note:   
 candidate expects 1 argument, 4 provided
 c:/gcdev/boost/include/boost/date_time/time_zone_names.hpp:49:9: note: 
 boost::date_time::time_zone_names_basechar::tim
 e_zone_names_base(boost::date_time::time_zone_names_basechar)
 c:/gcdev/boost/include/boost/date_time/time_zone_names.hpp:49:9: note:   
 candidate expects 1 argument, 4 provided
 At global scope:
 cc1plus.exe: error: unrecognized command line option 
 -Wno-deprecated-register [-Werror]
 cc1plus.exe: all warnings being treated as errors
 
 Will ponder further but you may beat me to an answer.
 

Robert,

Ah, right, tzi.StandardName and tzi.DaylightName are wchar_t[] and boost 
doesn’t know what to do with them. This revised patch might work.

Regards,
John Ralls


0001-Windows-Get-default-timezone-if-there-s-no-default-k.patch
Description: Binary data

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Windows Build failure

[John Ralls]

 On Jul 21, 2015, at 9:18 AM, John Ralls jra...@ceridwen.us wrote:
 
 
 On Jul 21, 2015, at 3:28 AM, Robert Fewell 14ubo...@gmail.com wrote:
 
 John,
 
 I have found a better windows version of gdb and have set the break point 
 and catch point as requested. Now running gnucash from gdb the exception 
 stems from getting time zone information from gnc-timezone.cpp:240 as can be 
 seen in attached image.
 
 Still trying to understand the c++ format but I think the registry keys are 
 different in Windows XP to that of later versions as my XP does not have 
 'TimeZoneKeyName' used in windows_default_tzname.
 
 
 Robert,
 
 Hmm, the C version of that code in GLib and GC 2.4 doesn’t have a problem on 
 XP, so I must have screwed something up when I ported it; it might just be 
 throwing that exception, which is a bad idea since it can’t be caught in the 
 way I’m using it. Since I can’t test on Windows until the weekend, if I can 
 manage a patch before then I’ll send it to you to test.
 
 If you’re completely new to C++, Lipmann’s C++ Primer Plus is widely 
 recommended.

Robert,

Here’s a first try at a patch. I can’t even test compile it until I get back 
tomorrow afternoon, but you can have a go at it and maybe fix any obvious typos.

Regards,
John Ralls



0001-Windows-Get-default-timezone-if-there-s-no-default-k.patch
Description: Binary data
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Windows Build failure

[John Ralls]

 On Jul 21, 2015, at 3:28 AM, Robert Fewell 14ubo...@gmail.com wrote:
 
 John,
 
 I have found a better windows version of gdb and have set the break point and 
 catch point as requested. Now running gnucash from gdb the exception stems 
 from getting time zone information from gnc-timezone.cpp:240 as can be seen 
 in attached image.
 
 Still trying to understand the c++ format but I think the registry keys are 
 different in Windows XP to that of later versions as my XP does not have 
 'TimeZoneKeyName' used in windows_default_tzname.
 

Robert,

Hmm, the C version of that code in GLib and GC 2.4 doesn’t have a problem on 
XP, so I must have screwed something up when I ported it; it might just be 
throwing that exception, which is a bad idea since it can’t be caught in the 
way I’m using it. Since I can’t test on Windows until the weekend, if I can 
manage a patch before then I’ll send it to you to test.

If you’re completely new to C++, Lipmann’s C++ Primer Plus is widely 
recommended.

Regards,
John Ralls

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Windows Build failure

[Robert Fewell]

OK, deleted all folders in gcdev apart from the git ones and reran the vb
script and then the install.sh file. This recompiled all dependencies and
also gnucash.

Tried to start it from the gcdev/gnucash/inst/bin/gnucash-launcher.cmd
which failed as boost libraries was not in path.
Added new path entry to cmd file and now it fails with a Runtime Error.

Had a look at the Nightly Builds and the last one that installed and ran
straight off was on 29/04/2015 and about says version 15a0d5d

These have stopped building since the 19/06/2015.

All other later builds install but fail to run as missing
libboost_date_time.dll, thought I could copy the one I had created in
gcdev/boost to the bin folder but that results in the Runtime Error.

Not sure what else I can try.

Regards,

 Bob

On 16 July 2015 at 00:58, John Ralls jra...@ceridwen.us wrote:


  On Jul 15, 2015, at 8:51 AM, Robert Fewell 14ubo...@gmail.com wrote:
 
  I tried to build the windows version on my XP VM but it failed with the
  following error...
  Did a git pull on gnucash-on-windows.git and gnucash.git to get the
 latest
  builds and then ran the install.sh under mingw which updated some parts
 of
  the software as usual but the gnucash sections fails.
 
  Have I failed to upgrade some component part ?
 
  Regards,
 
 Bob
 
 
  make  all-recursive
  make[1]: Entering directory `/c/gcdev/gnucash/build'
  Making all in .
  make[2]: Entering directory `/c/gcdev/gnucash/build'
  gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I/c/gcdev/gnucash.git
  -I/c/gcdev/regex/include -I/c/gcdev/gnome/include -I/c/gcdev
  /guile/include -I/c/gcdev/libdbi/include -I/c/gcdev/gwenhywfar/include
  -I/c/gcdev/hh/include -mms-bitfields -Ic:/gcdev/l
  ibsoup/include/libsoup-2.4 -Ic:/gcdev/gnome/include/libxml2
  -Ic:/gcdev/gnome/include/glib-2.0 -Ic:/gcdev/gnome/lib/glib-
  2.0/include   -D_WIN32  -pthread -Ic:/gcdev/guile/include
  -I/c/gcdev/readline/include -I/c/gcdev/regex/include   -g  -st
  d=gnu99 -mms-bitfields -g  -MT gnc_guile-guile.o -MD -MP -MF
  .deps/gnc_guile-guile.Tpo -c -o gnc_guile-guile.o `test -f
  'util/guile.c' || echo '/c/gcdev/gnucash.git/'`util/guile.c
  In file included from c:\gcdev\mingw\include\unistd.h:95:0,
  from c:/gcdev/guile/include/libguile/stime.h:27,
  from c:/gcdev/guile/include/libguile.h:91,
  from c:/gcdev/gnucash.git/util/guile.c:32:
  c:\gcdev\mingw\include\parts\time.h:65:8: error: redefinition of 'struct
  timespec'
  struct timespec
 ^
  In file included from c:/gcdev/guile/include/libguile/__scm.h:52:0,
  from c:/gcdev/guile/include/libguile.h:30,
  from c:/gcdev/gnucash.git/util/guile.c:32:
  c:/gcdev/guile/include/libguile/scmconfig.h:114:16: note: originally
  defined here
  typedef struct timespec scm_t_timespec;

 That’s from a Makefile that needs to be rebuilt. Delete the build
 directory and start from scratch.

 Regards,
 John Ralls



___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Windows Build failure

[John Ralls]

 On Jul 20, 2015, at 4:05 AM, Robert Fewell 14ubo...@gmail.com wrote:
 
 OK, deleted all folders in gcdev apart from the git ones and reran the vb 
 script and then the install.sh file. This recompiled all dependencies and 
 also gnucash.
 
 Tried to start it from the gcdev/gnucash/inst/bin/gnucash-launcher.cmd which 
 failed as boost libraries was not in path.
 Added new path entry to cmd file and now it fails with a Runtime Error.
 
 Had a look at the Nightly Builds and the last one that installed and ran 
 straight off was on 29/04/2015 and about says version 15a0d5d
 
 These have stopped building since the 19/06/2015.
 
 All other later builds install but fail to run as missing 
 libboost_date_time.dll, thought I could copy the one I had created in 
 gcdev/boost to the bin folder but that results in the Runtime Error.
 
 Not sure what else I can try.

Robert,

I did a build by hand last week after cleaning the build dir, which is what 
stopped the last automatic build. There hasn’t been a commit to master since to 
trigger a new automatic build.

I’m heading out of town for the week, so I won’t be able to look at the Windows 
runtime until the weekend. 

Since there were completed builds in May and June I guess you mean that none of 
the bundles actually runs because libboost_date_time.dll isn’t in the bundle. I 
guess that’s not surprising except that I thought I’d set up the build of boost 
so that date_time would be header-only. That part should be easy to fix.

What’s the runtime error?

Regards,
John Ralls


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Windows Build failure

[Robert Fewell]

John,


All the builds in May and June will install and if you start one it stops
saying it can not find libboost_date_time.dll. If I copy that dll from the
gcdev/boost/lib to the gnucash/bin directory you get the Runtime Error
straight away as attached.

Robert

On 20 July 2015 at 15:22, John Ralls jra...@ceridwen.us wrote:


  On Jul 20, 2015, at 4:05 AM, Robert Fewell 14ubo...@gmail.com wrote:
 
  OK, deleted all folders in gcdev apart from the git ones and reran the
 vb script and then the install.sh file. This recompiled all dependencies
 and also gnucash.
 
  Tried to start it from the gcdev/gnucash/inst/bin/gnucash-launcher.cmd
 which failed as boost libraries was not in path.
  Added new path entry to cmd file and now it fails with a Runtime Error.
 
  Had a look at the Nightly Builds and the last one that installed and ran
 straight off was on 29/04/2015 and about says version 15a0d5d
 
  These have stopped building since the 19/06/2015.
 
  All other later builds install but fail to run as missing
 libboost_date_time.dll, thought I could copy the one I had created in
 gcdev/boost to the bin folder but that results in the Runtime Error.
 
  Not sure what else I can try.

 Robert,

 I did a build by hand last week after cleaning the build dir, which is
 what stopped the last automatic build. There hasn’t been a commit to master
 since to trigger a new automatic build.

 I’m heading out of town for the week, so I won’t be able to look at the
 Windows runtime until the weekend.

 Since there were completed builds in May and June I guess you mean that
 none of the bundles actually runs because libboost_date_time.dll isn’t in
 the bundle. I guess that’s not surprising except that I thought I’d set up
 the build of boost so that date_time would be header-only. That part should
 be easy to fix.

 What’s the runtime error?

 Regards,
 John Ralls


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Windows Build failure

[John Ralls]

 On Jul 20, 2015, at 9:57 AM, Robert Fewell 14ubo...@gmail.com wrote:
 
 I had but I do not think I was doing it correctly, see attached, once I click 
 on OK I get the program exited with code 03.
 

Robert,

OK, that means it’s terminating either from an unhandled exception or an 
assert. Set a breakpoint on exit() with “b exit and a catchpoint with “catch 
exception unhandled”. See 
https://sourceware.org/gdb/onlinedocs/gdb/Breakpoints.html#Breakpoints for 
details.

Regards,
John Ralls
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Windows Build failure

[John Ralls]

 On Jul 20, 2015, at 7:41 AM, Robert Fewell 14ubo...@gmail.com wrote:
 
 John,
 
 
 All the builds in May and June will install and if you start one it stops 
 saying it can not find libboost_date_time.dll. If I copy that dll from the 
 gcdev/boost/lib to the gnucash/bin directory you get the Runtime Error 
 straight away as attached.

Robert,

Ah. Have you tried it in gdb?

Regards,
John Ralls


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Windows Build failure

[John Ralls]

 On Jul 20, 2015, at 10:59 AM, John Ralls jra...@ceridwen.us wrote:
 
 
 On Jul 20, 2015, at 9:57 AM, Robert Fewell 14ubo...@gmail.com wrote:
 
 I had but I do not think I was doing it correctly, see attached, once I 
 click on OK I get the program exited with code 03.
 
 
 Robert,
 
 OK, that means it’s terminating either from an unhandled exception or an 
 assert. Set a breakpoint on exit() with “b exit and a catchpoint with “catch 
 exception unhandled”. See 
 https://sourceware.org/gdb/onlinedocs/gdb/Breakpoints.html#Breakpoints for 
 details.

Robert,

BTW, I had some extra time this morning before leaving and did a build and dist 
on Win7. Works fine. That might be because I don’t have a “pure” system, but I 
fixed up the boost stuff in install and dist in gnucash-on-windows and pushed 
it.

Regards,
John Ralls


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Windows Build failure

[John Ralls]

 On Jul 15, 2015, at 8:51 AM, Robert Fewell 14ubo...@gmail.com wrote:
 
 I tried to build the windows version on my XP VM but it failed with the
 following error...
 Did a git pull on gnucash-on-windows.git and gnucash.git to get the latest
 builds and then ran the install.sh under mingw which updated some parts of
 the software as usual but the gnucash sections fails.
 
 Have I failed to upgrade some component part ?
 
 Regards,
 
Bob
 
 
 make  all-recursive
 make[1]: Entering directory `/c/gcdev/gnucash/build'
 Making all in .
 make[2]: Entering directory `/c/gcdev/gnucash/build'
 gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I/c/gcdev/gnucash.git
 -I/c/gcdev/regex/include -I/c/gcdev/gnome/include -I/c/gcdev
 /guile/include -I/c/gcdev/libdbi/include -I/c/gcdev/gwenhywfar/include
 -I/c/gcdev/hh/include -mms-bitfields -Ic:/gcdev/l
 ibsoup/include/libsoup-2.4 -Ic:/gcdev/gnome/include/libxml2
 -Ic:/gcdev/gnome/include/glib-2.0 -Ic:/gcdev/gnome/lib/glib-
 2.0/include   -D_WIN32  -pthread -Ic:/gcdev/guile/include
 -I/c/gcdev/readline/include -I/c/gcdev/regex/include   -g  -st
 d=gnu99 -mms-bitfields -g  -MT gnc_guile-guile.o -MD -MP -MF
 .deps/gnc_guile-guile.Tpo -c -o gnc_guile-guile.o `test -f
 'util/guile.c' || echo '/c/gcdev/gnucash.git/'`util/guile.c
 In file included from c:\gcdev\mingw\include\unistd.h:95:0,
 from c:/gcdev/guile/include/libguile/stime.h:27,
 from c:/gcdev/guile/include/libguile.h:91,
 from c:/gcdev/gnucash.git/util/guile.c:32:
 c:\gcdev\mingw\include\parts\time.h:65:8: error: redefinition of 'struct
 timespec'
 struct timespec
^
 In file included from c:/gcdev/guile/include/libguile/__scm.h:52:0,
 from c:/gcdev/guile/include/libguile.h:30,
 from c:/gcdev/gnucash.git/util/guile.c:32:
 c:/gcdev/guile/include/libguile/scmconfig.h:114:16: note: originally
 defined here
 typedef struct timespec scm_t_timespec;

That’s from a Makefile that needs to be rebuilt. Delete the build directory and 
start from scratch.

Regards,
John Ralls



___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Windows build broken

[John Ralls]

On May 8, 2014, at 5:19 PM, Geert Janssens janssens-ge...@telenet.be wrote:

 The merge of private-kvp introduces the use of g_list_copy_deep in 
 src/libqof/qof/kvp-frame.c
 
 That is a very recent glib function, requiring glib 2.34 at least. 
 That's more recent than our baseline 2.28 (and the most recent available 
 on Windows).
 
 Is there a relatively simple alternative for this function ?

Sigh. I think I already fixed that in the infamous earlier merge commit, but it 
seems not have made it back from my Win32 VM.

Not hard to remember, though, and pushed in 71c31cc.

Regards,
John Ralls


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Windows build failures

[John Ralls]

On Nov 3, 2013, at 2:46 PM, Geert Janssens janssens-ge...@telenet.be wrote:

 I have noticed the windows builds are failing with this error:
 cc1.exe: warnings being treated as errors
 ../../../repos/src/gnome-utils/gnc-tree-view.c: In function 
 'gnc_tree_view_get_column_order':
 ../../../repos/src/gnome-utils/gnc-tree-view.c:851:5: error: format 
 '%lu' expects type 'long unsigned int', but argument 5 has type 'gsize'
 make[5]: *** [gnc-tree-view.lo] Error 1
 
 I have written that code. On linux (at least Fedora 19, 64-bit) gsize is 
 defined as unsigned long. It looks like that is not the case on a 32-bit 
 windows XP system.
 
 It's too late here now to look at it. But if no one beats me to it, I'll 
 try and fix it tomorrow.

Already fixed, committed, re-tagged, distchecked, and the tarballs on SF. ;-)

I resisted the temptation to take it out entirely, as it’s only for a debugging 
message, and changed it to a gulong.

Regards,
John Ralls
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Windows Build system fixes

[Christian Stimming]

Zitat von Frank H. Ellenberger f.ellenber...@online.de:

in between we got 2 weekly builds in
http://code.gnucash.org/builds/win32/2.4/.

Shouldn't they be accessible from www.gnucash.org? (I found the directory by
chance in bugzilla).

I added a link in
http://wiki.gnucash.org/wiki/Windows#Q:_Where_is_the_binary_installer.3F


The link in the wiki is fine. But on www.gnucash.org only the official  
releases should be promoted. The nightly builds are, well, just that:  
Nightly builds. The releases are something else and only the releases  
are announced on gnucash.org.


Thanks!

Christian


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Windows Build system fixes

[Derek Atkins]

Christian Stimming stimm...@tuhh.de writes:

 Zitat von Frank H. Ellenberger f.ellenber...@online.de:
 in between we got 2 weekly builds in
 http://code.gnucash.org/builds/win32/2.4/.

 Shouldn't they be accessible from www.gnucash.org? (I found the directory by
 chance in bugzilla).

 I added a link in
 http://wiki.gnucash.org/wiki/Windows#Q:_Where_is_the_binary_installer.3F

 The link in the wiki is fine. But on www.gnucash.org only the official
 releases should be promoted. The nightly builds are, well, just that:
 Nightly builds. The releases are something else and only the releases
 are announced on gnucash.org.

Perhaps a better thing to do would be to put a README.txt at
http://code.gnucash.org/builds/win32 and change the Daily Builds
section to point there instead of to the 'trunk' subdir.  Then we just
point everyone at the Daily Builds and mention that it's not just
trunk but also a weekly build of the stable branch for testing changes?

 Thanks!

 Christian

-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
   warl...@mit.eduPGP key available
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Windows Build system fixes

[Frank H. Ellenberger]

Hoi,

in between we got 2 weekly builds in 
http://code.gnucash.org/builds/win32/2.4/.

Shouldn't they be accessible from www.gnucash.org? (I found the directory by 
chance in bugzilla).

I added a link in 
http://wiki.gnucash.org/wiki/Windows#Q:_Where_is_the_binary_installer.3F

Frank

Am Mittwoch, 23. März 2011 um 22:52:07 schrieb Geert Janssens:
:
 Ok, trunk can build the Windows port again, even when it has to set up a
 fresh mingw runtime and build environment. I had to fix one more bug in the
 scripts used on the build server to fix the failing upload. While writing
 this mail, I realize this commit (r20460) should have been marked for
 backporting. I clearly still have to get into the habit...

 To summarize:
 The guile/gcc patches applied in trunk, require a mingw update. At the time
 the 2.4 branch was created, the build scripts don't deal well with this. So
 I have committed some improvements to the build scripts to solve this. This
 now works fine on trunk, but for automated builds to work well for the 2.4
 branch and newer 2.4.x releases, a number of these patches should be
 backported to the 2.4 branch. It concerns these commits:
 http://svn.gnucash.org/trac/changeset/20452
 http://svn.gnucash.org/trac/changeset/20454
 http://svn.gnucash.org/trac/changeset/20455
 http://svn.gnucash.org/trac/changeset/20456
 http://svn.gnucash.org/trac/changeset/20457
 http://svn.gnucash.org/trac/changeset/20460

 Geert
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Windows Build system fixes

[Christian Stimming]

Zitat von Geert Janssens janssens-ge...@telenet.be:
Ok, trunk can build the Windows port again, even when it has to set  
up a fresh

mingw runtime and build environment.


Thanks a lot for your effort here.

Tonight's build unfortunately failed again, but that one goes on me:

libtool: compile:  gcc -DHAVE_CONFIG_H (...) -c  
swig-app-utils-python.c  -DDLL_EXPORT -DPIC -o  
.libs/swig-app-utils-python.o
swig-app-utils-python.c:124:20: fatal error: Python.h: No such file or  
directory

compilation terminated.

The last patch I committed switched on compiling of a python library  
of the app-utils.i swig wrappers, but it switched this on  
unconditionally. Hence, as we don't have any python installed in our  
windows build system, it can't do anything else than failing. I'll fix  
that later tonight so that this parts won't get built unless  
--enable-python[-bindings] was given at configure time. Sorry for that.



This now
works fine on trunk, but for automated builds to work well for the 2.4 branch
and newer 2.4.x releases, a number of these patches should be backported to
the 2.4 branch. It concerns these commits:
http://svn.gnucash.org/trac/changeset/20452
http://svn.gnucash.org/trac/changeset/20454
http://svn.gnucash.org/trac/changeset/20455
http://svn.gnucash.org/trac/changeset/20456
http://svn.gnucash.org/trac/changeset/20457
http://svn.gnucash.org/trac/changeset/20460


Sure. Feel free to cherry-pick those yourself, or otherwise anyone  
else can do that as well. I think I won't get to this before next  
week, but if it's still not yet done by then, I can do that as well.


Best Regards,

Christian

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Windows Build system fixes

[Derek Atkins]

Christian Stimming stimm...@tuhh.de writes:

 Thanks a lot for your effort here.

 Tonight's build unfortunately failed again, but that one goes on me:

 libtool: compile:  gcc -DHAVE_CONFIG_H (...) -c
 swig-app-utils-python.c  -DDLL_EXPORT -DPIC -o
 .libs/swig-app-utils-python.o
 swig-app-utils-python.c:124:20: fatal error: Python.h: No such file or
 directory
 compilation terminated.

 The last patch I committed switched on compiling of a python library
 of the app-utils.i swig wrappers, but it switched this on
 unconditionally. Hence, as we don't have any python installed in our
 windows build system, it can't do anything else than failing. I'll fix
 that later tonight so that this parts won't get built unless
 --enable-python[-bindings] was given at configure time. Sorry for
 that.

Well, this is why we have the nightly builds, to catch these things
earlier, rather than later.  :)

The only thing we DONT have, yet, is automated emailing of build
failures.

-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
   warl...@mit.eduPGP key available
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Windows Build system fixes

[Derek Atkins]

Geert Janssens janssens-ge...@telenet.be writes:

 I will wait at least until tomorrow before backporting, just to see if 
 tonight's build doesn't reveal bugs in my changes.

Unfortunately last night's build failed, and it failed pretty quickly.
If you make further changes today I recommend you fire off a build
manually to check that it works.

 Geert

-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
   warl...@mit.eduPGP key available
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Windows Build system fixes

[Geert Janssens]

On woensdag 23 maart 2011, Derek Atkins wrote:
 Geert Janssens janssens-ge...@telenet.be writes:
  I will wait at least until tomorrow before backporting, just to see if
  tonight's build doesn't reveal bugs in my changes.
 
 Unfortunately last night's build failed, and it failed pretty quickly.
 If you make further changes today I recommend you fire off a build
 manually to check that it works.
 
  Geert
 
 -derek
Yes, I was already looking into it.

The first problem was that newer mingw packages are distributed in lzma 
compression. Our build scripts don't install lzma tools to extract these. It 
turns out that MSys itself ships lzma starting from version 1.0.11. The build 
server had 1.0.10. I have updated that now.

I'm hitting a problem now while building autotools, but from the errors it 
seems to be a problem of mingw not properly installed. I'm short on time right 
now, but will look at it further later on.

Geert
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Windows Build system fixes

[Elise Scher]

Hi people,
About 10 hours ago, I downloaded gnucash and installed it on my Samsung
netbook running Windows XP. I feel I need to become familiar with the system
from the users' side. I like working on something where I can use both the
technical and business side of me.
I have to go to work soon. So I will be offline for a few hours. I am
substituting today in Palo Alto.

Thank you for the opportunity,
Elise L. Scher


On Wed, Mar 23, 2011 at 6:03 AM, Geert Janssens
janssens-ge...@telenet.bewrote:

 On woensdag 23 maart 2011, Derek Atkins wrote:
  Geert Janssens janssens-ge...@telenet.be writes:
   I will wait at least until tomorrow before backporting, just to see if
   tonight's build doesn't reveal bugs in my changes.
 
  Unfortunately last night's build failed, and it failed pretty quickly.
  If you make further changes today I recommend you fire off a build
  manually to check that it works.
 
   Geert
 
  -derek
 Yes, I was already looking into it.

 The first problem was that newer mingw packages are distributed in lzma
 compression. Our build scripts don't install lzma tools to extract these.
 It
 turns out that MSys itself ships lzma starting from version 1.0.11. The
 build
 server had 1.0.10. I have updated that now.

 I'm hitting a problem now while building autotools, but from the errors it
 seems to be a problem of mingw not properly installed. I'm short on time
 right
 now, but will look at it further later on.

 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

Re: Windows Build system fixes

[Geert Janssens]

On woensdag 23 maart 2011, Geert Janssens wrote:
 On woensdag 23 maart 2011, Derek Atkins wrote:
  Geert Janssens janssens-ge...@telenet.be writes:
   I will wait at least until tomorrow before backporting, just to see if
   tonight's build doesn't reveal bugs in my changes.
  
  Unfortunately last night's build failed, and it failed pretty quickly.
  If you make further changes today I recommend you fire off a build
  manually to check that it works.
  
   Geert
  
  -derek
 
 Yes, I was already looking into it.
 
 The first problem was that newer mingw packages are distributed in lzma
 compression. Our build scripts don't install lzma tools to extract these.
 It turns out that MSys itself ships lzma starting from version 1.0.11. The
 build server had 1.0.10. I have updated that now.
 
 I'm hitting a problem now while building autotools, but from the errors it
 seems to be a problem of mingw not properly installed. I'm short on time
 right now, but will look at it further later on.
 
 Geert

Ok, I have added some fixes.

There were two problems so far:
1. I ran all my local tests in an environment that had the older mingw 
installed, which I had upgraded by the build scripts by removing g++. However 
when I let the buildscripts setup a clean mingw, it turned out there was one 
component missing: the mingwrt dev package. This caused the libtool build to 
fail. I have fixed this in the build scripts. They now do setup a proper mingw 
environment, including everything necessary to build.

2. Next I had created a patch in order to make guile 1.8.8 buid properly. I 
forgot to check this one it. Done now. The build is running now. We'll see in 
a couple of hours if it is successful this time.

Geert
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Windows Build system fixes

[Geert Janssens]

On woensdag 23 maart 2011, Geert Janssens wrote:
 On woensdag 23 maart 2011, Geert Janssens wrote:
  On woensdag 23 maart 2011, Derek Atkins wrote:
   Geert Janssens janssens-ge...@telenet.be writes:
I will wait at least until tomorrow before backporting, just to see
if tonight's build doesn't reveal bugs in my changes.
   
   Unfortunately last night's build failed, and it failed pretty quickly.
   If you make further changes today I recommend you fire off a build
   manually to check that it works.
   
Geert
   
   -derek
  
  Yes, I was already looking into it.
  
  The first problem was that newer mingw packages are distributed in lzma
  compression. Our build scripts don't install lzma tools to extract these.
  It turns out that MSys itself ships lzma starting from version 1.0.11.
  The build server had 1.0.10. I have updated that now.
  
  I'm hitting a problem now while building autotools, but from the errors
  it seems to be a problem of mingw not properly installed. I'm short on
  time right now, but will look at it further later on.
  
  Geert
 
 Ok, I have added some fixes.
 
 There were two problems so far:
 1. I ran all my local tests in an environment that had the older mingw
 installed, which I had upgraded by the build scripts by removing g++.
 However when I let the buildscripts setup a clean mingw, it turned out
 there was one component missing: the mingwrt dev package. This caused the
 libtool build to fail. I have fixed this in the build scripts. They now do
 setup a proper mingw environment, including everything necessary to build.
 
 2. Next I had created a patch in order to make guile 1.8.8 buid properly. I
 forgot to check this one it. Done now. The build is running now. We'll see
 in a couple of hours if it is successful this time.
 
 Geert

Ok, trunk can build the Windows port again, even when it has to set up a fresh 
mingw runtime and build environment. I had to fix one more bug in the scripts 
used on the build server to fix the failing upload. While writing this mail, I 
realize this commit (r20460) should have been marked for backporting. I 
clearly still have to get into the habit...

To summarize:
The guile/gcc patches applied in trunk, require a mingw update. At the time 
the 2.4 branch was created, the build scripts don't deal well with this. So I 
have committed some improvements to the build scripts to solve this. This now 
works fine on trunk, but for automated builds to work well for the 2.4 branch 
and newer 2.4.x releases, a number of these patches should be backported to 
the 2.4 branch. It concerns these commits:
http://svn.gnucash.org/trac/changeset/20452
http://svn.gnucash.org/trac/changeset/20454
http://svn.gnucash.org/trac/changeset/20455
http://svn.gnucash.org/trac/changeset/20456
http://svn.gnucash.org/trac/changeset/20457
http://svn.gnucash.org/trac/changeset/20460

Geert
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Windows Build System

[Derek Atkins]

Stephen Brown stephengrantbr...@mcmedia.com.au writes:

 Hi Geert and others
 I also believe that GnuCash development should focus on, well, GnuCash.
 I do too, that is why I am suggesting that the proccess to build
 gnucash on Microsoft Windows
 should just work and work correctly everytime. I want to develope
 GnuCash, but I cannot if
 I have to continually go back and  debug the build proccess. I do not
 have the knowledge to debug the
 build system.
 Yours Sincerely Stephen Grant Brown. 

One approach would be to pre-build the necessary dependencies and make
them available publically.  This way someone who wants to build
GnuCash need only download the pre-built dependencies and install them.
This can be automated (similar to the current automation).

Note that we already do this for e.g. webkit.

I think being able to update individual dependencies is a good thing.
Having a single GnuCash SDK bundle would make it much harder to
upgrade individual dependencies.

-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
   warl...@mit.eduPGP key available
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Windows Build System

[Stephen Brown]

Hi Geert and others

I also believe that GnuCash development should focus on, well, GnuCash.
I do too, that is why I am suggesting that the proccess to build gnucash on 
Microsoft Windows
should just work and work correctly everytime. I want to develope GnuCash, 
but I cannot if
I have to continually go back and  debug the build proccess. I do not have 
the knowledge to debug the

build system.
Yours Sincerely Stephen Grant Brown. 


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Windows Build System

[Geert Janssens]

On zaterdag 5 maart 2011, Stephen Brown wrote:
 Hi Geert
 
 Mine are to take all the instructions in
 http://wiki.gnucash.org/wiki/Windows#Q:_Is_it_possible_to_compile_GnuCash_o
 n_Windows.3F, compile it
 into a windows executable file, include the other programs mentioned, and
 make the whole lot available so that some one can download it, run it, and
 have gnucash built on their Microsoft Windows machine with minimal user
 input.
 
 Yours Sincerely Stephen Grant Brown

While I consider it quite an achievement to get a complext piece of code such 
as GnuCash to build on Windows, there are a couple of things that I'm not too 
happy with in the Windows build process.

For starters, the whole build is one big shell script. It does the job, but it 
lacks many features of a complete build system. I'm thinking of systems like 
automake, cmake, jhbuild,... Those systems would handle dependency changes 
more gracefully.

I also believe that GnuCash development should focus on, well, GnuCash. All 
the other items that are built via the script are actually support libraries. 
Having the script to verify each of these dependencies before actually 
starting a GnuCash build takes valuable time. In fact, that every developer 
has to do that at least once while setting up the development environment for 
the first time is a shared loss of time.
So here I play with the idea to build some kind of gnucash-support-libs sdk 
that can simply be installed via an installer program by anyone that likes to 
do some GnuCash development on windows. Only one dev has to build this sdk and 
publish it on the GnuCash website. All others can simply download and install 
it and focus on GnuCash from there on. When one of the support libraries has 
to be updates, a new sdk installer is built which can then be installed by the 
other devs.

I realize that the idea of a preinstalled sdk conflicts with the concept of 
jhbuild, which builds everything from scratch. But these are only rough ideas 
anyway, not something ready for implementation yet.

Geert
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Windows Build 2.3.10 r18664 - dead on arrival!

[Derek Atkins]

Kim Wood kim.w...@bigpond.net.au writes:

 WTF?  But 2.3.10-setup.exe (74Mb) runs fine.  It also reports itself also as
 build r18664, but with a different file size to Windows nightly build r18664
 (76Mb).  Anyway, there you go...  At least 2.3.10 runs fine.

The tag build and nightly build could be the same revision depending on
if there were any more commits between the tag and the build time.
That's why they both report r18664.

As for the size difference -- the tag build rebuilds all the
dependencies from source, whereas the nightly build never rebuilds
dependencies.  So the nightly build could be using way-old libraries. 

Hope this explains the differences.

 Regards,

 Kim

-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
   warl...@mit.eduPGP key available
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Windows Build 2.3.10 r18664 - dead on arrival!

[Kim Wood]

WTF?  But 2.3.10-setup.exe (74Mb) runs fine.  It also reports itself also as
build r18664, but with a different file size to Windows nightly build r18664
(76Mb).  Anyway, there you go...  At least 2.3.10 runs fine.

Regards,

Kim

-- 
View this message in context: 
http://n4.nabble.com/Windows-Build-2-3-10-r18664-dead-on-arrival-tp1558502p1558569.html
Sent from the GnuCash - Dev mailing list archive at Nabble.com.
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Windows Build 2.3.10 r18664 - dead on arrival!

[Geert Janssens]

On Wednesday 17 February 2010, Kim Wood wrote:
 WTF?  But 2.3.10-setup.exe (74Mb) runs fine.  It also reports itself also
  as build r18664, but with a different file size to Windows nightly build
  r18664 (76Mb).  Anyway, there you go...  At least 2.3.10 runs fine.
 
 Regards,
 
 Kim
 
The revision naming is confusing.

2.3.10 is really r18662, but at the time it got built, two more commits were 
made in the trunk, making the most recent revision number r18664.

But the two later commits don't affect the 2.3.10 build:
2.3.10 is built from gnucash/tags/2.3.10
the nighlies are built from gnucash/trunk

The later commits were on trunk only.

I suspect it's changeset r18664 that is causing this: it updates a number of 
gnome packages, including libpng.

I'm not sure yet what goes wrong though...

Geert
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Windows build failed, r18541 incompatible with guile-1.6

[Derek Atkins]

Geert Janssens janssens-ge...@telenet.be writes:

[snip]
 Is the problem sufficiently solved with Christian's guile-compat.h fix ? If 
 not, I can look into an alternative solution.

I believe that yes, this solved the problem.

Thanks,

 Regards,

 Geert (who is learning every day...)

-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
   warl...@mit.eduPGP key available
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Windows build failed, r18541 incompatible with guile-1.6

[Geert Janssens]

On Monday 4 January 2010, Christian Stimming wrote:
 Am Montag, 4. Januar 2010 schrieb Derek Atkins:
   The first compile problem with r18541 is one of many guile-1.6
   functions which Geert replaced with their non-deprecated guile-1.8
   counterparts, such as SCM_NFALSEP - scm_is_true. But even if we
   reverted all of that cosmetics, the main part of fixing bug#582325 is
   still a problem because guile-1.6 doesn't have scm_to_locale_string.
   Or, in other words, bug#582325 doesn't occur in guile-1.6 but only in
   the recent guile-1.8 but there it can be fixed only by using a new
   guile function which is not yet available in the old guile version.
  
   Maybe we should provide a #define workaround for scm_to_locale_string
   if guile-1.6 is detected, and (unfortunately) revert the rest of the
   renamings?
 
  Maybe we should do what David Hampton did and just recreate a
  guile-compat.h that we can use to provide a guile-1.8 compatibility for
  guile-1.6?
 
 Yes, I've committed something like this just right now.
 
  What does scm_to_locale_string() do?
 
 Dunno. The explanation at bug#582325 contains some text about this.
 
 Regards,
 
 Christian
 ___
 gnucash-devel mailing list
 gnucash-devel@gnucash.org
 https://lists.gnucash.org/mailman/listinfo/gnucash-devel
 

My apologies for leaving you guys with this mess... I didn't realize that the 
1.8 replacement functions were not available in 1.6.

scm_locale_to_string is a function that converts an SCM variable into a C-
compatible string. This is exactly what the older SCM_STRING_CHARS did as 
well. On recent distributions (Fedora 12, Mandriva 2009.1,...), GnuCash 
started crashing on SCM_STRING_CHARS, although this is not purely due to 
SCM_STRING_CHARS itself.

As of guile 1.8.6 there is a change in guile's symbol-string function that 
makes it incompatible with SCM_STRING_CHARS. A lot of guile code in GnuCash 
uses symbol-string in combination with SCM_STRING_CHARS, which doesn't work 
anymore as of Guile 1.8.6.

As SCM_STRING_CHARS was marked as deprecated, I figured the easiest solution 
would be to replace it with its proposed new equivalent (which also is more 
i10n compliant). As said, I didn't fully realize this change was incompatible 
with guile 1.6. I should have checked that.

Is the problem sufficiently solved with Christian's guile-compat.h fix ? If 
not, I can look into an alternative solution.

Regards,

Geert (who is learning every day...)
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Windows build failed

[Derek Atkins]

Simon Ruggier simo...@gmail.com writes:

 Perhaps it's misleading to say that one can't build GnuCash against
 Debian's guile-1.8 packages, since the missing guile-1.8-slib package
 would only create two files, which can be manually installed by doing
 the following as root:
 ln -s ../../slib/ /usr/share/guile/1.8/
 guile -c (use-modules (ice-9 slib)) (require 'new-catalog)

 After doing the above, I can build successfully using Debian's
 guile-1.8-dev package. I don't know anything about Guile, so I can't
 comment on how this issue could or should be handled on other
 platforms.

However, losing guile-1.6 support without discussion is a BAD THING.

-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
   warl...@mit.eduPGP key available
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Windows build failed, r18541 incompatible with guile-1.6

[Christian Stimming]

Am Montag, 4. Januar 2010 schrieb Derek Atkins:
 Simon Ruggier simo...@gmail.com writes:
  After doing the above, I can build successfully using Debian's
  guile-1.8-dev package. I don't know anything about Guile, so I can't
  comment on how this issue could or should be handled on other
  platforms.
 
 However, losing guile-1.6 support without discussion is a BAD THING.

The problem with current trunk and windows (i.e. guile-1.6) is that Geert 
Janssens committed r18541 claiming that the replacement SCM_STRING_CHARS - 
scm_to_locale_string is necessary to fix bug#582325, Crash when setting Fancy 
Date format (with lenghtly explanations there). Geert then informed us he 
will be out of town until at least January 10th, which explained why he hasn't 
replied to any of the questions here.

The first compile problem with r18541 is one of many guile-1.6 functions which 
Geert replaced with their non-deprecated guile-1.8 counterparts, such as 
SCM_NFALSEP - scm_is_true. But even if we reverted all of that cosmetics, 
the main part of fixing bug#582325 is still a problem because guile-1.6 
doesn't have scm_to_locale_string. Or, in other words, bug#582325 doesn't 
occur in guile-1.6 but only in the recent guile-1.8 but there it can be fixed 
only by using a new guile function which is not yet available in the old guile 
version.

Maybe we should provide a #define workaround for scm_to_locale_string if 
guile-1.6 is detected, and (unfortunately) revert the rest of the renamings?

Christian
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Windows build failed, r18541 incompatible with guile-1.6

[Derek Atkins]

Christian Stimming stimm...@tuhh.de writes:

 Am Montag, 4. Januar 2010 schrieb Derek Atkins:
 Simon Ruggier simo...@gmail.com writes:
  After doing the above, I can build successfully using Debian's
  guile-1.8-dev package. I don't know anything about Guile, so I can't
  comment on how this issue could or should be handled on other
  platforms.
 
 However, losing guile-1.6 support without discussion is a BAD THING.

 The problem with current trunk and windows (i.e. guile-1.6) is that Geert 
 Janssens committed r18541 claiming that the replacement SCM_STRING_CHARS - 
 scm_to_locale_string is necessary to fix bug#582325, Crash when setting 
 Fancy 
 Date format (with lenghtly explanations there). Geert then informed us he 
 will be out of town until at least January 10th, which explained why he 
 hasn't 
 replied to any of the questions here.

 The first compile problem with r18541 is one of many guile-1.6 functions 
 which 
 Geert replaced with their non-deprecated guile-1.8 counterparts, such as 
 SCM_NFALSEP - scm_is_true. But even if we reverted all of that cosmetics, 
 the main part of fixing bug#582325 is still a problem because guile-1.6 
 doesn't have scm_to_locale_string. Or, in other words, bug#582325 doesn't 
 occur in guile-1.6 but only in the recent guile-1.8 but there it can be fixed 
 only by using a new guile function which is not yet available in the old 
 guile 
 version.

 Maybe we should provide a #define workaround for scm_to_locale_string if 
 guile-1.6 is detected, and (unfortunately) revert the rest of the renamings?

Maybe we should do what David Hampton did and just recreate a
guile-compat.h that we can use to provide a guile-1.8 compatibility for
guile-1.6?

What does scm_to_locale_string() do?

 Christian

-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
   warl...@mit.eduPGP key available
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Windows build failed, r18541 incompatible with guile-1.6

[Christian Stimming]

Am Montag, 4. Januar 2010 schrieb Derek Atkins:
  The first compile problem with r18541 is one of many guile-1.6 functions
  which Geert replaced with their non-deprecated guile-1.8 counterparts,
  such as SCM_NFALSEP - scm_is_true. But even if we reverted all of that
  cosmetics, the main part of fixing bug#582325 is still a problem
  because guile-1.6 doesn't have scm_to_locale_string. Or, in other words,
  bug#582325 doesn't occur in guile-1.6 but only in the recent guile-1.8
  but there it can be fixed only by using a new guile function which is not
  yet available in the old guile version.
 
  Maybe we should provide a #define workaround for scm_to_locale_string if
  guile-1.6 is detected, and (unfortunately) revert the rest of the
  renamings?
 
 Maybe we should do what David Hampton did and just recreate a
 guile-compat.h that we can use to provide a guile-1.8 compatibility for
 guile-1.6?

Yes, I've committed something like this just right now.

 What does scm_to_locale_string() do?

Dunno. The explanation at bug#582325 contains some text about this.

Regards,

Christian
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Windows build failed

[Simon Ruggier]

It's from revision 18541, and I just bumped into it on Debian. It
looks like that function is present in guile 1.8, but not 1.6. Right
now, one can't build GnuCash against Debian's guile 1.8 packages yet,
because no guile-1.8-slib is provided. There's a Debian bug about
this, #441110, but it looks like it's slipped through the cracks or
something.
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Windows build failed

[Simon Ruggier]

Perhaps it's misleading to say that one can't build GnuCash against
Debian's guile-1.8 packages, since the missing guile-1.8-slib package
would only create two files, which can be manually installed by doing
the following as root:
ln -s ../../slib/ /usr/share/guile/1.8/
guile -c (use-modules (ice-9 slib)) (require 'new-catalog)

After doing the above, I can build successfully using Debian's
guile-1.8-dev package. I don't know anything about Guile, so I can't
comment on how this issue could or should be handled on other
platforms.
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: windows build and MSYS exceptions

[Derek Atkins]

Hi,

Hale Boyes, Kevin  [EMAIL PROTECTED] writes:

[snip]
 Then,

 if /bin/sh ../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I.
 -I. -I.. -I../include -I../generic-g -O2 -MT EntityManager.lo -MD
 -MP -MF .deps/EntityManager.Tpo -c -o EntityManager.lo
 EntityManager.cxx; \
 then mv -f .deps/EntityManager.Tpo .deps/EntityManager.Plo; else rm
 -f .deps/EntityManager.Tpo; exit 1; fi
   0 [main] sh 3256 open_stackdumpfile: Dumping stack trace to
 sh.exe.stackdump
  g++ -DHAVE_CONFIG_H -I. -I. -I.. -I../include -I../generic -g -O2 -MT
 EntityManager.lo -MD -MP -MF  -c EntityManager.cxx  -DDLL_EXPORT -DPIC
 -o .libs/EntityManager.o
 mv: cannot stat `.deps/EntityManager.Tpo': No such file or directory
 make[1]: *** [EntityManager.lo] Error 1
 make[1]: Leaving directory `/d/gnucash-win32/tmp/OpenSP-1.5.2/lib'
 make: *** [all] Error 2
 make: Leaving directory `/d/gnucash-win32/tmp/OpenSP-1.5.2/lib'

This COULD be a race condition.  On Win32 you cannot rename or unlink
and open file, so sometimes if you have multiple CPUs the build can
fail when the rename happens before the close().

 If I restart install.sh it might fail at a different place in OpenSP
 or, as has previously happened, it will finish the compile and
 installation
 of this dependency and move on to the next.  Then it might fail later.
 I've restarted the install about 5 times so far due to this problem.

Yeah, when you hit this race condition, all you can really do is
restart the build.  I'm not sure if there's a global way to tell
make to use only one thread, and even if there is I don't know if
it would solve this race condition.

[stack trace snipped]

Huh.  I have no idea what this stack trace is all about.  I've
never seen THAT before.

 MSYS-1.0.10 Build:2004-03-15 07:17
 Exception: STATUS_ACCESS_VIOLATION at eip=71070C43
 eax=7FFDE000 ebx= ecx= edx=0022DA08 esi=
 edi=0022D828
 ebp=0022D3CC esp=0022D3A8 program=D:\gnucash-win32\msys\bin\sh.exe
 cs=001B ds=0023 es=0023 fs=003B gs= ss=0023
 Stack trace:
[snip]

This certainly seems to be sh failing..  But I bet it's the
make shell, probably as a result of the race condition.

 But it always seems to be a STATUS_ACCESS_VIOLATION.  A look on
 google didn't really turn up anything, short of re-install windows,
 so I thought I ask here.

 Has anyone seen this or know what is going on?

I'm afraid not.

Any reason you don't just install the win32 binary installer?

-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: windows build and MSYS exceptions

[Hale Boyes, Kevin]

I'm running the build on a single CPU here so I have no idea about
it being a race condition.  Seems my latest build, over night, got
a lot further than ever before so I'll just stick with the retry
method.

About the binary installer...  I've been using gnucash for a number
of years (on linux) and work as a developer so I've wanted to get
a build version up and running.  Unfortunately, I'm currently working
in a windows environment so when I get a spare cycle during the day
I have a go at the build.  Also, by building my own copy
on windows I can help test the build process and eventually test a
running windows-based gnucash.  Down the road, if I ever get there,
there is a new features that I'd like to try to implement.  My small
way of contributing to a product that I rely on.


Thanks,
Kevin.


-Original Message-
From: Derek Atkins [mailto:[EMAIL PROTECTED] 
Sent: Thursday, April 19, 2007 8:37 AM
To: Hale Boyes, Kevin 
Cc: gnucash-devel@gnucash.org
Subject: Re: windows build and MSYS exceptions

Hi,

Hale Boyes, Kevin  [EMAIL PROTECTED] writes:

[snip]
 Then,

 if /bin/sh ../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I.
 -I. -I.. -I../include -I../generic-g -O2 -MT EntityManager.lo -MD
 -MP -MF .deps/EntityManager.Tpo -c -o EntityManager.lo
 EntityManager.cxx; \
 then mv -f .deps/EntityManager.Tpo .deps/EntityManager.Plo; else
rm
 -f .deps/EntityManager.Tpo; exit 1; fi
   0 [main] sh 3256 open_stackdumpfile: Dumping stack trace to
 sh.exe.stackdump
  g++ -DHAVE_CONFIG_H -I. -I. -I.. -I../include -I../generic -g -O2 -MT
 EntityManager.lo -MD -MP -MF  -c EntityManager.cxx  -DDLL_EXPORT
-DPIC
 -o .libs/EntityManager.o
 mv: cannot stat `.deps/EntityManager.Tpo': No such file or directory
 make[1]: *** [EntityManager.lo] Error 1
 make[1]: Leaving directory `/d/gnucash-win32/tmp/OpenSP-1.5.2/lib'
 make: *** [all] Error 2
 make: Leaving directory `/d/gnucash-win32/tmp/OpenSP-1.5.2/lib'

This COULD be a race condition.  On Win32 you cannot rename or unlink
and open file, so sometimes if you have multiple CPUs the build can
fail when the rename happens before the close().

 If I restart install.sh it might fail at a different place in OpenSP
 or, as has previously happened, it will finish the compile and
 installation
 of this dependency and move on to the next.  Then it might fail later.
 I've restarted the install about 5 times so far due to this problem.

Yeah, when you hit this race condition, all you can really do is
restart the build.  I'm not sure if there's a global way to tell
make to use only one thread, and even if there is I don't know if
it would solve this race condition.

[stack trace snipped]

Huh.  I have no idea what this stack trace is all about.  I've
never seen THAT before.

 MSYS-1.0.10 Build:2004-03-15 07:17
 Exception: STATUS_ACCESS_VIOLATION at eip=71070C43
 eax=7FFDE000 ebx= ecx= edx=0022DA08 esi=
 edi=0022D828
 ebp=0022D3CC esp=0022D3A8 program=D:\gnucash-win32\msys\bin\sh.exe
 cs=001B ds=0023 es=0023 fs=003B gs= ss=0023
 Stack trace:
[snip]

This certainly seems to be sh failing..  But I bet it's the
make shell, probably as a result of the race condition.

 But it always seems to be a STATUS_ACCESS_VIOLATION.  A look on
 google didn't really turn up anything, short of re-install windows,
 so I thought I ask here.

 Has anyone seen this or know what is going on?

I'm afraid not.

Any reason you don't just install the win32 binary installer?

-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

This email communication and any files transmitted with it may contain 
confidential and or proprietary information and is provided for the use of the 
intended recipient only. Any review, retransmission or dissemination of this 
information by anyone other than the intended recipient is prohibited.  If you 
receive this email in error, please contact the sender and delete this 
communication and any copies immediately. Thank you. 
http://www.encana.com



___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

RE: windows build failed

[Hale Boyes, Kevin]

I was simply curious about the IRC logs.  Nothing else.
I'll try the g++ install.

Thanks for your help,
Kevin.
 

-Original Message-
From: Derek Atkins [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, April 18, 2007 12:12 PM
To: Hale Boyes, Kevin 
Cc: gnucash-devel@gnucash.org
Subject: Re: windows build failed

Quoting Hale Boyes, Kevin  [EMAIL PROTECTED]:

[snip]
 checking for g++... no
 checking for c++... no
 checking for gpp... no
 checking for aCC... no
 checking for CC... no
 checking for cxx... no
 checking for cc++... no
[snip]
 checking whether we are using the GNU C++ compiler... no
 checking whether g++ accepts -g... no
 checking dependency style of g++... none
 checking how to run the C++ preprocessor... /lib/cpp
 configure: error: C++ preprocessor /lib/cpp fails sanity check
 See `config.log' for more details.

 I'd include the config.log but it is long and probably not necessary.
 I'll just include the bits that _I_ think point to the problem.

 configure:3539: checking for C++ compiler version
 configure:3542: g++ --version /dev/null 5
 ./configure: g++: command not found

 I guess I didn't install g++.  I think that was supposed to happen
 during the MinGW install but I don't remember.  Can I install g++
 now so that the install can proceed or do I have to start over?
 Is it as simple as re-running the MinGW installer
 (manually running $GLOBAL_DIR/downloads/MinGW-5.1.0.exe)?

Yep, that should work.  And yes, you need to install g++.  Unfortunately
there's not really a good way to automate that.  When you install g++
just make sure it gets installed into the right place.

 If I may ask an unrelated question...  How often are the daily
 IRC logs updated?

Um, should be nearly instantaneous.  Why?
I'm pretty sure it's just a script that runs tail -f on the logfile
and outputs that into the HTML logs available online.

 Thanks for your help,
 Kevin.

-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


This email communication and any files transmitted with it may contain 
confidential and or proprietary information and is provided for the use of the 
intended recipient only. Any review, retransmission or dissemination of this 
information by anyone other than the intended recipient is prohibited.  If you 
receive this email in error, please contact the sender and delete this 
communication and any copies immediately. Thank you. 
http://www.encana.com



___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: windows build and r15912

[Derek Atkins]

Perhaps we should pull in custom.sh first, and then have
defaults.sh do something like:

[ -z ${GLOBAL_DIR:-} ]  GLOBAL_DIR=default

.. and do this for all the variables to only set them if
they are not already set.

-derek

Hale Boyes, Kevin  [EMAIL PROTECTED] writes:

 Maybe my scripting skill are a bit rusty but how is the
 new defaults/custom file loading going to work?

 The only value that I normally change is the GLOBAL_DIR setting.
 When I create the custom file, will it contain just the GLOBAL_DIR
 variable or do I need to copy the entire defaults file and
 change just the one variable?

 I'm guessing that I need to do the later because of all the
 variables that depend on the value of GLOBAL_DIR (like DOCS_DIR).
 They will be set before the custom file is sourced and their
 value won't change when I reset the value of GLOBAL_DIR.

 Hmm, I guess I'll have to be more careful than that.  I won't
 want an exact copy of defaults as that would call all the add_step
 functions again.

 In an attempt to answer my own question...  If I want to change the
 value of GLOBAL_DIR then I will put it and all the variable that
 depend on it into the custom file, but nothing else.  It isn't enough
 to put just GLOBAL_DIR into custom.

 Is that correct?

 Thanks,
 Kevin.

 This email communication and any files transmitted with it may contain 
 confidential and or proprietary information and is provided for the use of 
 the intended recipient only. Any review, retransmission or dissemination of 
 this information by anyone other than the intended recipient is prohibited.  
 If you receive this email in error, please contact the sender and delete this 
 communication and any copies immediately. Thank you. 
 http://www.encana.com



 ___
 gnucash-devel mailing list
 gnucash-devel@gnucash.org
 https://lists.gnucash.org/mailman/listinfo/gnucash-devel



-- 
   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: windows build and r15912

[Andreas Köhler]

Hi,

very good point, Kevin.  Somehow I forgot about it.
Derek, that is almost exactly what I am going to implement now.  The 
head of defaults should explain it once I have it running and committed.

-- andi5

Derek Atkins schrieb:
 Perhaps we should pull in custom.sh first, and then have
 defaults.sh do something like:
 
 [ -z ${GLOBAL_DIR:-} ]  GLOBAL_DIR=default
 
 .. and do this for all the variables to only set them if
 they are not already set.
 
 -derek
 
 Hale Boyes, Kevin  [EMAIL PROTECTED] writes:
 
 Maybe my scripting skill are a bit rusty but how is the
 new defaults/custom file loading going to work?

 The only value that I normally change is the GLOBAL_DIR setting.
 When I create the custom file, will it contain just the GLOBAL_DIR
 variable or do I need to copy the entire defaults file and
 change just the one variable?

 I'm guessing that I need to do the later because of all the
 variables that depend on the value of GLOBAL_DIR (like DOCS_DIR).
 They will be set before the custom file is sourced and their
 value won't change when I reset the value of GLOBAL_DIR.

 Hmm, I guess I'll have to be more careful than that.  I won't
 want an exact copy of defaults as that would call all the add_step
 functions again.

 In an attempt to answer my own question...  If I want to change the
 value of GLOBAL_DIR then I will put it and all the variable that
 depend on it into the custom file, but nothing else.  It isn't enough
 to put just GLOBAL_DIR into custom.

 Is that correct?

 Thanks,
 Kevin.
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

RE: windows build and r15912

[Hale Boyes, Kevin]

Great, I'll have a look when I see the commit message.
Kevin.

-Original Message-
From: Andreas Köhler [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, April 17, 2007 11:15 AM
To: Derek Atkins
Cc: Hale Boyes, Kevin ; gnucash-devel@gnucash.org
Subject: Re: windows build and r15912

Hi,

very good point, Kevin.  Somehow I forgot about it.
Derek, that is almost exactly what I am going to implement now.  The 
head of defaults should explain it once I have it running and committed.

-- andi5

Derek Atkins schrieb:
 Perhaps we should pull in custom.sh first, and then have
 defaults.sh do something like:
 
 [ -z ${GLOBAL_DIR:-} ]  GLOBAL_DIR=default
 
 .. and do this for all the variables to only set them if
 they are not already set.
 
 -derek
 
 Hale Boyes, Kevin  [EMAIL PROTECTED] writes:
 
 Maybe my scripting skill are a bit rusty but how is the
 new defaults/custom file loading going to work?

 The only value that I normally change is the GLOBAL_DIR setting.
 When I create the custom file, will it contain just the GLOBAL_DIR
 variable or do I need to copy the entire defaults file and
 change just the one variable?

 I'm guessing that I need to do the later because of all the
 variables that depend on the value of GLOBAL_DIR (like DOCS_DIR).
 They will be set before the custom file is sourced and their
 value won't change when I reset the value of GLOBAL_DIR.

 Hmm, I guess I'll have to be more careful than that.  I won't
 want an exact copy of defaults as that would call all the add_step
 functions again.

 In an attempt to answer my own question...  If I want to change the
 value of GLOBAL_DIR then I will put it and all the variable that
 depend on it into the custom file, but nothing else.  It isn't enough
 to put just GLOBAL_DIR into custom.

 Is that correct?

 Thanks,
 Kevin.

This email communication and any files transmitted with it may contain 
confidential and or proprietary information and is provided for the use of the 
intended recipient only. Any review, retransmission or dissemination of this 
information by anyone other than the intended recipient is prohibited.  If you 
receive this email in error, please contact the sender and delete this 
communication and any copies immediately. Thank you. 
http://www.encana.com



___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: windows build and r15912

[Andreas Köhler]

Hi,

see r15918.  I hope it works for you, please drop me a note about your 
observations :)

-- andi5

Hale Boyes, Kevin schrieb:
 Great, I'll have a look when I see the commit message.
 Kevin.
 
 -Original Message-
 From: Andreas Köhler [mailto:[EMAIL PROTECTED] 
 Sent: Tuesday, April 17, 2007 11:15 AM
 To: Derek Atkins
 Cc: Hale Boyes, Kevin ; gnucash-devel@gnucash.org
 Subject: Re: windows build and r15912
 
 Hi,
 
 very good point, Kevin.  Somehow I forgot about it.
 Derek, that is almost exactly what I am going to implement now.  The 
 head of defaults should explain it once I have it running and committed.
 
 -- andi5
 
 Derek Atkins schrieb:
 Perhaps we should pull in custom.sh first, and then have
 defaults.sh do something like:

 [ -z ${GLOBAL_DIR:-} ]  GLOBAL_DIR=default

 .. and do this for all the variables to only set them if
 they are not already set.

[...]
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

RE: windows build and r15912

[Hale Boyes, Kevin]

This looks pretty good.  I put my single override in custom and 
it seems to be working well.  I'm just running install.sh now
(it takes a while on my machine).  The addition of the sample
custom script at the top of defaults is very helpful.

Thanks,
K.


-Original Message-
From: Andreas Köhler [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, April 17, 2007 1:51 PM
To: Hale Boyes, Kevin 
Cc: Derek Atkins; gnucash-devel@gnucash.org
Subject: Re: windows build and r15912

Hi,

see r15918.  I hope it works for you, please drop me a note about your 
observations :)

-- andi5

Hale Boyes, Kevin schrieb:
 Great, I'll have a look when I see the commit message.
 Kevin.
 
 -Original Message-
 From: Andreas Köhler [mailto:[EMAIL PROTECTED] 
 Sent: Tuesday, April 17, 2007 11:15 AM
 To: Derek Atkins
 Cc: Hale Boyes, Kevin ; gnucash-devel@gnucash.org
 Subject: Re: windows build and r15912
 
 Hi,
 
 very good point, Kevin.  Somehow I forgot about it.
 Derek, that is almost exactly what I am going to implement now.  The 
 head of defaults should explain it once I have it running and committed.
 
 -- andi5
 
 Derek Atkins schrieb:
 Perhaps we should pull in custom.sh first, and then have
 defaults.sh do something like:

 [ -z ${GLOBAL_DIR:-} ]  GLOBAL_DIR=default

 .. and do this for all the variables to only set them if
 they are not already set.

[...]

This email communication and any files transmitted with it may contain 
confidential and or proprietary information and is provided for the use of the 
intended recipient only. Any review, retransmission or dissemination of this 
information by anyone other than the intended recipient is prohibited.  If you 
receive this email in error, please contact the sender and delete this 
communication and any copies immediately. Thank you. 
http://www.encana.com



___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Windows build and gtkprint

[David Reiser]

Can I blame my incompetence on Windows? Getting rid of the gnucash  
build and install directories (plus rebuilding libgsf and goffice, if  
that matters) solved both problems.

On 24 Mar 2007, at 8:25:36 PM, David Reiser wrote:

 My first attempt at building r15753 under winXP (also upgraded gnome
 to include gtkhtml3.14) ends with:

 ../../../repos/src/gnome-utils/gnc-html.c: In function  
 `gnc_html_print':
 ../../../repos/src/gnome-utils/gnc-html.c:1273: warning: implicit
 declaration of function `gtk_html_print'
 make[5]: *** [gnc-html.lo] Error 1
 make[5]: Leaving directory `/c/soft/gnucash/build/src/gnome-utils'
 make[4]: *** [all-recursive] Error 1
 make[4]: Leaving directory `/c/soft/gnucash/build/src/gnome-utils'
 make[3]: *** [all] Error 2

 I also had to put libgnomeprintui back in because libgnomeprint
 depends on it...

 Dave

--
David Reiser
[EMAIL PROTECTED]

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: windows build problems

[Andreas Köhler]

Hi,

Am Dienstag, den 20.03.2007, 17:14 -0400 schrieb Dave Reiser:
 Attempting to build r15742 on winxp I end up at:

I have to admit that I have not tested r15742 on Windows yet.

 make[5]: *** No rule to make target `libgncmod_gnome_utils_la_SOURCES', 
 needed by `libgncmod-gnome-utils.la'.  Stop.
 make[5]: Leaving directory `/c/soft/gnucash/build/src/gnome-utils'
 make[4]: *** [all-recursive] Error 1
 
 I also get a warning a little earlier:
 
 *** Warning: linker path does not have real file for library -lhtmlhelp.
 *** I have the capability to make that library automatically link in when
 *** you link to this library.  But I can only do this if you have a
 *** shared version of the library, which you do not appear to have
 *** because I did check the linker path looking for a file starting
 *** with libhtmlhelp and none of the candidates passed a file format test
 *** using a file magic. Last file checked: /c/soft/gnome/lib/libiconv.a
 *** The inter-library dependencies that have been dropped here will be
 *** automatically added whenever a program is linked with this library
 *** or is declared to -dlopen it.
 
 *** Since this library must not contain undefined symbols,
 *** because either the platform does not support them or
 *** it was explicitly requested with -no-undefined,
 *** libtool will only create a static version of it.
 
 But htmlhelp.lib is in /c/soft/hh/lib, and HH_LDFLAGS=-L/c/soft/hh/lib 
 is exported by profile.d/installer.sh

That is weird.  In r15727 I added a test in inst_hh to make sure we can
really compile and link a test file similar to gnc-help-utils.c.  So if
you use install.sh, it should fail.  Also, I do not have
c:/soft/hh/lib/htmlhelp.lib, because it is moved to htmlhelp.lib.bak.
You should rather have libhtmlhelp.a.

 Dave

-- andi5


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: windows build problems

[David Reiser]

On 20 Mar 2007, at 5:51:19 PM, Andreas Köhler wrote:

 Hi,

 Am Dienstag, den 20.03.2007, 17:14 -0400 schrieb Dave Reiser:
 Attempting to build r15742 on winxp I end up at:

 I have to admit that I have not tested r15742 on Windows yet.

 make[5]: *** No rule to make target  
 `libgncmod_gnome_utils_la_SOURCES',
 needed by `libgncmod-gnome-utils.la'.  Stop.
 make[5]: Leaving directory `/c/soft/gnucash/build/src/gnome-utils'
 make[4]: *** [all-recursive] Error 1

Hmm. I might have screwed up something else too. Maybe it's time to  
wipe most of that install clean and redo it...


 I also get a warning a little earlier:

 *** Warning: linker path does not have real file for library - 
 lhtmlhelp.
 *** I have the capability to make that library automatically link  
 in when
 *** you link to this library.  But I can only do this if you have a
 *** shared version of the library, which you do not appear to have
 *** because I did check the linker path looking for a file starting
 *** with libhtmlhelp and none of the candidates passed a file  
 format test
 *** using a file magic. Last file checked: /c/soft/gnome/lib/ 
 libiconv.a
 *** The inter-library dependencies that have been dropped here  
 will be
 *** automatically added whenever a program is linked with this  
 library
 *** or is declared to -dlopen it.

 *** Since this library must not contain undefined symbols,
 *** because either the platform does not support them or
 *** it was explicitly requested with -no-undefined,
 *** libtool will only create a static version of it.

 But htmlhelp.lib is in /c/soft/hh/lib, and HH_LDFLAGS=-L/c/soft/ 
 hh/lib
 is exported by profile.d/installer.sh

 That is weird.  In r15727 I added a test in inst_hh to make sure we  
 can
 really compile and link a test file similar to gnc-help-utils.c.   
 So if
 you use install.sh, it should fail.  Also, I do not have
 c:/soft/hh/lib/htmlhelp.lib, because it is moved to htmlhelp.lib.bak.
 You should rather have libhtmlhelp.a.

I just checked on the old laptop, and it has the correct help file  
library. The one at work doesn't. I probably caused that when I let  
it install hh to the default location, and then just tried to rename  
the directory. Silly me.

It looks like r15739 is going to finish successfully on the home  
laptop. Time to nuke the work machine...

Thanks for changing the fumble-fingered Subject:


 Dave

 -- andi5

Dave
--
David Reiser
[EMAIL PROTECTED]


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel