Re: r21768 - gnucash/branches/2.4/packaging/win32 - More changes to compile gtk-2.24.
On Jan 8, 2012, at 11:30 AM, Geert Janssens wrote:
> Op zaterdag 31 december 2011 15:29:37 schreef John Ralls:
>> The problem is that like most unix programs, guile hardcodes its
>> installation prefix into the binary and generally expects to find
>> everything it needs relative to that prefix for ever after. For loading
>> modules, that can be overridden with GUILE_LOAD_PATH, which we do in the
>> environment file that gets loaded at gnucash startup.
>>
>> Slib has another quirk, though: It sets an internal variable named
>> "implementation-vicinity to prefix and tries to write slibcat there. If
>> that directory doesn't exist (c:/soft-2.4 in this case), it barfs -- and
>> because the error handling in that part of guile.init is wrong, it returns
>> a message about the scheme file that creates the catalog, mklibcat, not
>> being found.
>>
>> The good news is that there's another environment variable,
>> GUILE_IMPLEMENTATION_PATH, which overrides the compiled-in prefix, and
>> setting that in gnucash's environment file seems to fix the problem. I'll
>> commit the appropriate change to gnucash.iss.in as soon as I verify that I
>> have the inno syntax right, and we'll see if tomorrow's build works.
>>
>> The thing that puzzles me a bit is that that's not what trunk does, and I
>> don't see how it gets around the problem. It doesn't put the slibcat in
>> {GNC_HOME}/share/guile/1.8 -- or anywhere else that I can find. I guess
>> we'll have to wait for Geert to get back to find out that little puzzle.
>>
> Well, trunk has ditched slib altogether, so slibcat is no longer called. That
> seems to work fine. The patches to eliminate slib came from Andy Wingo, not
> myself. I'm afraid that's all I can add here.
D'oh. No slib, no need to work around its problems.
Thanks.
Regards,
John Ralls
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: r21768 - gnucash/branches/2.4/packaging/win32 - More changes to compile gtk-2.24.
Op zaterdag 31 december 2011 15:29:37 schreef John Ralls:
> The problem is that like most unix programs, guile hardcodes its
> installation prefix into the binary and generally expects to find
> everything it needs relative to that prefix for ever after. For loading
> modules, that can be overridden with GUILE_LOAD_PATH, which we do in the
> environment file that gets loaded at gnucash startup.
>
> Slib has another quirk, though: It sets an internal variable named
> "implementation-vicinity to prefix and tries to write slibcat there. If
> that directory doesn't exist (c:/soft-2.4 in this case), it barfs -- and
> because the error handling in that part of guile.init is wrong, it returns
> a message about the scheme file that creates the catalog, mklibcat, not
> being found.
>
> The good news is that there's another environment variable,
> GUILE_IMPLEMENTATION_PATH, which overrides the compiled-in prefix, and
> setting that in gnucash's environment file seems to fix the problem. I'll
> commit the appropriate change to gnucash.iss.in as soon as I verify that I
> have the inno syntax right, and we'll see if tomorrow's build works.
>
> The thing that puzzles me a bit is that that's not what trunk does, and I
> don't see how it gets around the problem. It doesn't put the slibcat in
> {GNC_HOME}/share/guile/1.8 -- or anywhere else that I can find. I guess
> we'll have to wait for Geert to get back to find out that little puzzle.
>
Well, trunk has ditched slib altogether, so slibcat is no longer called. That
seems to work fine. The patches to eliminate slib came from Andy Wingo, not
myself. I'm afraid that's all I can add here.
Geert
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: r21768 - gnucash/branches/2.4/packaging/win32 - More changes to compile gtk-2.24.
On Dec 31, 2011, at 1:39 PM, Derek Atkins wrote:
>
> On Sat, December 31, 2011 2:45 pm, John Ralls wrote:
>>
>> On Dec 31, 2011, at 10:47 AM, Derek Atkins wrote:
>>
>>> guile -c "(use-modules (ice-9 slib)) (require 'new-catalog)"
>>>
>>> Maybe we just need to do this in our install.sh script?
That's not necessary with slib3. It's smart enough to recognize that it needs a
catalog and create one as part of it's "require" function. We actually have
that line in gnucash.iss.in, but it was a no-op because it was never called.
For the real problem, read on.
>>>
>>
>> Oh, it's there. But it's calling guile.cmd, and there isn't one.
>> I see that it works for me when I test because guile.exe can find the
>> guile installation directory which was compiled in, even when the
>> installer puts it in c:\Program Files\gnucash. The guile built on the
>> buildbot must have a different path (even though I'm building in c:\soft),
>> so it can't even find ice-9/boot-9.
>
> 2.4 on buildbot is in c:\soft-2.4
>
> It is POSSIBLE that there is a guile in the buildbot path that is NOT the
> guile that's part of the 2.4 build. Would that cause this problem?
No.
The problem is that like most unix programs, guile hardcodes its installation
prefix into the binary and generally expects to find everything it needs
relative to that prefix for ever after. For loading modules, that can be
overridden with GUILE_LOAD_PATH, which we do in the environment file that gets
loaded at gnucash startup.
Slib has another quirk, though: It sets an internal variable named
"implementation-vicinity to prefix and tries to write slibcat there. If that
directory doesn't exist (c:/soft-2.4 in this case), it barfs -- and because the
error handling in that part of guile.init is wrong, it returns a message about
the scheme file that creates the catalog, mklibcat, not being found.
The good news is that there's another environment variable,
GUILE_IMPLEMENTATION_PATH, which overrides the compiled-in prefix, and setting
that in gnucash's environment file seems to fix the problem. I'll commit the
appropriate change to gnucash.iss.in as soon as I verify that I have the inno
syntax right, and we'll see if tomorrow's build works.
The thing that puzzles me a bit is that that's not what trunk does, and I don't
see how it gets around the problem. It doesn't put the slibcat in
{GNC_HOME}/share/guile/1.8 -- or anywhere else that I can find. I guess we'll
have to wait for Geert to get back to find out that little puzzle.
Regards,
John Ralls
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: r21768 - gnucash/branches/2.4/packaging/win32 - More changes to compile gtk-2.24.
On Sat, December 31, 2011 2:45 pm, John Ralls wrote: > > On Dec 31, 2011, at 10:47 AM, Derek Atkins wrote: > >> guile -c "(use-modules (ice-9 slib)) (require 'new-catalog)" >> >> Maybe we just need to do this in our install.sh script? >> > > Oh, it's there. But it's calling guile.cmd, and there isn't one. > I see that it works for me when I test because guile.exe can find the > guile installation directory which was compiled in, even when the > installer puts it in c:\Program Files\gnucash. The guile built on the > buildbot must have a different path (even though I'm building in c:\soft), > so it can't even find ice-9/boot-9. 2.4 on buildbot is in c:\soft-2.4 It is POSSIBLE that there is a guile in the buildbot path that is NOT the guile that's part of the 2.4 build. Would that cause this problem? > > Regards, > John Ralls -derek -- Derek Atkins 617-623-3745 de...@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: r21768 - gnucash/branches/2.4/packaging/win32 - More changes to compile gtk-2.24.
On Dec 31, 2011, at 10:47 AM, Derek Atkins wrote: > Hi, > > On Sat, December 31, 2011 1:39 pm, John Ralls wrote: >> >> On Dec 31, 2011, at 1:38 AM, Geert Janssens wrote: >> >> >>> On a side note: starting tomorrow I won't be much near my computer for a >>> week, >>> so if there are things that need my feedback, it make take some time >>> before I >>> can answer. >> >> It didn't work: >> >> In c:\Program Files\gnucash/share/guile/1.8/slib/require.scm: >> 141: 2 (cond ((not feature) (set! *catalog* #f)) ((slib:provided? >> feature)) . ..) > [snip] >> 205: 9 [with-load-pathname "c:\\Program >> Files\\gnucash/share/guile/1.8/slib/m klibcat" ...] >> In c:\Program Files\gnucash/share/guile/1.8/slib/guile.init: >>... >> 308: 10 [dynamic-wind # # #> #f ()> ] >> In unknown file: >> ?: 11* [#] >> In c:\Program Files\gnucash/share/guile/1.8/slib/require.scm: >> 207: 12* [apply # #] >> In unknown file: >> ?: 13 [slib:load "c:\\Program >> Files\\gnucash/share/guile/1.8/slib/mklibcat"] >>... >> ?: 14 [dynamic-wind # # #> #f ()> ] >> ?: 15* [#] >> In c:\Program Files\gnucash/share/guile/1.8/slib/guile.init: >> 558: 16* (let* ((errinfo #)) (if (and errinfo #) (apply throw errinfo))) >> 561: 17 (if (and errinfo (catch # # #)) (apply throw errinfo)) >> In unknown file: >>... >> ?: 18 [throw] >> >> c:\Program Files\gnucash/share/guile/1.8/slib/guile.init:561:10: In >> procedure op en-file in expression (if (and errinfo #) (apply throw >> errinfo)): >> c:\Program Files\gnucash/share/guile/1.8/slib/guile.init:561:10: No such >> file or directory: "c:\\Program >> Files\\gnucash/share/guile/1.8/slib/mklibcat" >> >> Sigh. >> >> Regards, >> John Ralls > > This should be a simple fix where we just need to build the catalog file. > It can be done once, possibly during the build. It just requires someone > to run: > > guile -c "(use-modules (ice-9 slib)) (require 'new-catalog)" > > Maybe we just need to do this in our install.sh script? > Oh, it's there. But it's calling guile.cmd, and there isn't one. I see that it works for me when I test because guile.exe can find the guile installation directory which was compiled in, even when the installer puts it in c:\Program Files\gnucash. The guile built on the buildbot must have a different path (even though I'm building in c:\soft), so it can't even find ice-9/boot-9. Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: r21768 - gnucash/branches/2.4/packaging/win32 - More changes to compile gtk-2.24.
Hi, On Sat, December 31, 2011 1:39 pm, John Ralls wrote: > > On Dec 31, 2011, at 1:38 AM, Geert Janssens wrote: > > >> On a side note: starting tomorrow I won't be much near my computer for a >> week, >> so if there are things that need my feedback, it make take some time >> before I >> can answer. > > It didn't work: > > In c:\Program Files\gnucash/share/guile/1.8/slib/require.scm: > 141: 2 (cond ((not feature) (set! *catalog* #f)) ((slib:provided? > feature)) . ..) [snip] > 205: 9 [with-load-pathname "c:\\Program > Files\\gnucash/share/guile/1.8/slib/m klibcat" ...] > In c:\Program Files\gnucash/share/guile/1.8/slib/guile.init: > ... > 308: 10 [dynamic-wind # # # #f ()> ] > In unknown file: >?: 11* [#] > In c:\Program Files\gnucash/share/guile/1.8/slib/require.scm: > 207: 12* [apply # #] > In unknown file: >?: 13 [slib:load "c:\\Program > Files\\gnucash/share/guile/1.8/slib/mklibcat"] > ... >?: 14 [dynamic-wind # # # #f ()> ] >?: 15* [#] > In c:\Program Files\gnucash/share/guile/1.8/slib/guile.init: > 558: 16* (let* ((errinfo #)) (if (and errinfo #) (apply throw errinfo))) > 561: 17 (if (and errinfo (catch # # #)) (apply throw errinfo)) > In unknown file: > ... >?: 18 [throw] > > c:\Program Files\gnucash/share/guile/1.8/slib/guile.init:561:10: In > procedure op en-file in expression (if (and errinfo #) (apply throw > errinfo)): > c:\Program Files\gnucash/share/guile/1.8/slib/guile.init:561:10: No such > file or directory: "c:\\Program > Files\\gnucash/share/guile/1.8/slib/mklibcat" > > Sigh. > > Regards, > John Ralls This should be a simple fix where we just need to build the catalog file. It can be done once, possibly during the build. It just requires someone to run: guile -c "(use-modules (ice-9 slib)) (require 'new-catalog)" Maybe we just need to do this in our install.sh script? -derek -- Derek Atkins 617-623-3745 de...@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: r21768 - gnucash/branches/2.4/packaging/win32 - More changes to compile gtk-2.24.
On Dec 31, 2011, at 1:38 AM, Geert Janssens wrote: > Op vrijdag 30 december 2011 19:44:50 schreef John Ralls: >> On Dec 30, 2011, at 5:17 PM, Derek Atkins wrote: >>> What about backporting the feature table patch? >> >> Oh, did you commit that to trunk? I thought you'd done it direct to 2.4. If >> you don't beat me to it, I'll backport it tomorrow. >> >> Regards, >> John Ralls >> > It's backported now. If today's build works, we can tag as far as I'm > concerned. > > On a side note: starting tomorrow I won't be much near my computer for a > week, > so if there are things that need my feedback, it make take some time before I > can answer. It didn't work: In c:\Program Files\gnucash/share/guile/1.8/slib/require.scm: 141: 2 (cond ((not feature) (set! *catalog* #f)) ((slib:provided? feature)) . ..) 145: 3 (let* ((path #)) (cond (# #) (# # #) (# # #) ...)) 145: 4* [catalog:get hash-table] 76: 5* (if (not *catalog*) (let* ((slibcat #)) (cond (# # #)) ...)) 77: 6 (let* ((slibcat #)) (cond (# # #)) (cond (slibcat #)) ...) 78: 7* (cond ((not #) (slib:load-source #) (set! slibcat #))) 79: 8* [# "c:\\Program Files\\gnucash/share/guile/1.8/slib/mk libcat"] 205: 9 [with-load-pathname "c:\\Program Files\\gnucash/share/guile/1.8/slib/m klibcat" ...] In c:\Program Files\gnucash/share/guile/1.8/slib/guile.init: ... 308: 10 [dynamic-wind # # # ] In unknown file: ?: 11* [#] In c:\Program Files\gnucash/share/guile/1.8/slib/require.scm: 207: 12* [apply # #] In unknown file: ?: 13 [slib:load "c:\\Program Files\\gnucash/share/guile/1.8/slib/mklibcat"] ... ?: 14 [dynamic-wind # # # ] ?: 15* [#] In c:\Program Files\gnucash/share/guile/1.8/slib/guile.init: 558: 16* (let* ((errinfo #)) (if (and errinfo #) (apply throw errinfo))) 561: 17 (if (and errinfo (catch # # #)) (apply throw errinfo)) In unknown file: ... ?: 18 [throw] c:\Program Files\gnucash/share/guile/1.8/slib/guile.init:561:10: In procedure op en-file in expression (if (and errinfo #) (apply throw errinfo)): c:\Program Files\gnucash/share/guile/1.8/slib/guile.init:561:10: No such file or directory: "c:\\Program Files\\gnucash/share/guile/1.8/slib/mklibcat" Sigh. Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: r21768 - gnucash/branches/2.4/packaging/win32 - More changes to compile gtk-2.24.
Op vrijdag 30 december 2011 19:44:50 schreef John Ralls: > On Dec 30, 2011, at 5:17 PM, Derek Atkins wrote: > > What about backporting the feature table patch? > > Oh, did you commit that to trunk? I thought you'd done it direct to 2.4. If > you don't beat me to it, I'll backport it tomorrow. > > Regards, > John Ralls > It's backported now. If today's build works, we can tag as far as I'm concerned. On a side note: starting tomorrow I won't be much near my computer for a week, so if there are things that need my feedback, it make take some time before I can answer. Geert ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: r21768 - gnucash/branches/2.4/packaging/win32 - More changes to compile gtk-2.24.
On Dec 30, 2011, at 5:17 PM, Derek Atkins wrote: > What about backporting the feature table patch? > Oh, did you commit that to trunk? I thought you'd done it direct to 2.4. If you don't beat me to it, I'll backport it tomorrow. Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: r21768 - gnucash/branches/2.4/packaging/win32 - More changes to compile gtk-2.24.
What about backporting the feature table patch? -derek Sent from my HTC on the Now Network from Sprint! - Reply message - From: "John Ralls" Date: Fri, Dec 30, 2011 6:30 pm Subject: r21768 - gnucash/branches/2.4/packaging/win32 - More changes to compile gtk-2.24. To: Cc: On Dec 29, 2011, at 2:00 PM, John Ralls wrote: > > On Dec 27, 2011, at 10:09 PM, John Ralls wrote: > >> >> It's still not quite ready for release: Gnucash isn't noticing that AQB is >> present. > > Which turned out to be more WebKit contamination, sort of. Ktoblzcheck needs > a couple of libraries from mingw (libstdc++-6.dll and libgcc_s_dw2-1.dll) and > we were relying on WebKit to provide them -- but it only provides an older > version of libstdc++-1. > > > > We should be able to release 2.4.9 after checking tomorrow's build. Which failed. I hadn't changed the guile/1.6 reference in gnucash.iss.in. That's committed, and the package I built today installed and launched, so I think we can tag tomorrow, unless we want to wait till after New Year's day. Regards, John Ralls ___ 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: r21768 - gnucash/branches/2.4/packaging/win32 - More changes to compile gtk-2.24.
On Dec 29, 2011, at 2:00 PM, John Ralls wrote: > > On Dec 27, 2011, at 10:09 PM, John Ralls wrote: > >> >> It's still not quite ready for release: Gnucash isn't noticing that AQB is >> present. > > Which turned out to be more WebKit contamination, sort of. Ktoblzcheck needs > a couple of libraries from mingw (libstdc++-6.dll and libgcc_s_dw2-1.dll) and > we were relying on WebKit to provide them -- but it only provides an older > version of libstdc++-1. > > > > We should be able to release 2.4.9 after checking tomorrow's build. Which failed. I hadn't changed the guile/1.6 reference in gnucash.iss.in. That's committed, and the package I built today installed and launched, so I think we can tag tomorrow, unless we want to wait till after New Year's day. Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: r21768 - gnucash/branches/2.4/packaging/win32 - More changes to compile gtk-2.24.
Am Donnerstag, 29. Dezember 2011, 15:11:39 schrieb John Ralls: > >> Which turned out to be more WebKit contamination, sort of. Ktoblzcheck > >> needs a couple of libraries from mingw (libstdc++-6.dll and > >> libgcc_s_dw2-1.dll) and we were relying on WebKit to provide them -- > >> but it only provides an older version of libstdc++-1. > > > > Very interesting. Now, libktoblzcheck isn't anything miraculous - it's > > just a C++ library that we build ourselves. Apparently once we do this, > > the libstdc++ of the compiler needs to be present but hasn't been so > > far. > > > > This change is most probably also needed in trunk, isn't it? > > It wouldn't matter whether we built it or got a binary from somewhere: If it > links against libstdc++, it has to have it. C++ library symbols are > "mangled" in a compiler-specific way, so it's not possible to link a > program made with one compiler against a library made with another. But > that wasn't the problem here: The libstdc++-6 that WekKit provided didn't > define a symbol that ktoblzcheck wanted (__gxx_personality_v0), but there > are a couple of dozen others that it was perfectly happy with. That > indicates a libstdc++-6 version problem rather than a wrong compiler > problem. Yes: From the description it sounds as if webkit's libstdc++6 was older than the one of the mingw that we use. Hence the newer one of mingw has some symbol which the older one hasn't, and this is what the hand-compiled ktoblzcheck complains about. But I don't know libstdc++ version details here. > It looks to me from the symbols imported from libgcc_s_dw2-1 (Unwind_resume, > _deregister_frame_info, _moddi3, and _register_frame_info) that it has to > do with debugging, so we might be able to get rid of that dependency by > changing CFLAGS. I tried, but apparently linking against libstdc++ always pulls in this libgcc_s. There were no CFLAGS or similar that triggered the linking to this library, nor were there any that could be removed to remove this dependency. > I don't know if it needs changing in trunk. AQB works there, right? I haven't checked myself on windows, ever. From the gnucash-de mailing list reports apparently it does work. Regards, Christian ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: r21768 - gnucash/branches/2.4/packaging/win32 - More changes to compile gtk-2.24.
On Dec 29, 2011, at 2:20 PM, Christian Stimming wrote: > Am Donnerstag, 29. Dezember 2011, 14:00:51 schrieb John Ralls: >> On Dec 27, 2011, at 10:09 PM, John Ralls wrote: >>> It's still not quite ready for release: Gnucash isn't noticing that AQB >>> is present. >> Which turned out to be more WebKit contamination, sort of. Ktoblzcheck needs >> a couple of libraries from mingw (libstdc++-6.dll and libgcc_s_dw2-1.dll) >> and we were relying on WebKit to provide them -- but it only provides an >> older version of libstdc++-1. > > Very interesting. Now, libktoblzcheck isn't anything miraculous - it's just a > C++ library that we build ourselves. Apparently once we do this, the > libstdc++ > of the compiler needs to be present but hasn't been so far. > > This change is most probably also needed in trunk, isn't it? It wouldn't matter whether we built it or got a binary from somewhere: If it links against libstdc++, it has to have it. C++ library symbols are "mangled" in a compiler-specific way, so it's not possible to link a program made with one compiler against a library made with another. But that wasn't the problem here: The libstdc++-6 that WekKit provided didn't define a symbol that ktoblzcheck wanted (__gxx_personality_v0), but there are a couple of dozen others that it was perfectly happy with. That indicates a libstdc++-6 version problem rather than a wrong compiler problem. It looks to me from the symbols imported from libgcc_s_dw2-1 (Unwind_resume, _deregister_frame_info, _moddi3, and _register_frame_info) that it has to do with debugging, so we might be able to get rid of that dependency by changing CFLAGS. I don't know if it needs changing in trunk. AQB works there, right? Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: r21768 - gnucash/branches/2.4/packaging/win32 - More changes to compile gtk-2.24.
Am Donnerstag, 29. Dezember 2011, 14:00:51 schrieb John Ralls: > On Dec 27, 2011, at 10:09 PM, John Ralls wrote: > > It's still not quite ready for release: Gnucash isn't noticing that AQB > > is present. > Which turned out to be more WebKit contamination, sort of. Ktoblzcheck needs > a couple of libraries from mingw (libstdc++-6.dll and libgcc_s_dw2-1.dll) > and we were relying on WebKit to provide them -- but it only provides an > older version of libstdc++-1. Very interesting. Now, libktoblzcheck isn't anything miraculous - it's just a C++ library that we build ourselves. Apparently once we do this, the libstdc++ of the compiler needs to be present but hasn't been so far. This change is most probably also needed in trunk, isn't it? Thank you very much! Regards, Christian ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: r21768 - gnucash/branches/2.4/packaging/win32 - More changes to compile gtk-2.24.
Done. -derek On Wed, December 28, 2011 9:30 am, Geert Janssens wrote: > Op woensdag 28 december 2011 09:09:05 schreef Derek Atkins: >> Hi, >> >> On Wed, December 28, 2011 8:36 am, Geert Janssens wrote: >> > Op dinsdag 27 december 2011 22:09:51 schreef John Ralls: >> >> So with the changes checked in (and a reset.sh), it should build a >> >> working >> >> package... at least, it does here. >> > >> > I wanted to perform the reset.sh, but at this time the connection to >> the >> > build >> > server fails. >> > >> > Unless Derek does it first, I'll try again later. >> >> It looks like the vmware management interface crashed. (I really need to >> look into a new/better VM hosting solution, considering vmware-server >> was >> EOLed in June). I restarted the management interface so now it should >> connect. >> > Thanks > >> I've run reset.sh from /c/soft-2,4/packaging. Is there somewhere else >> it >> needs to be run? >> > I would start the weekly_build.sh script in the same directory, to get an > intermediate build to look at. Otherwise we'll have to wait until > tomorrow. > > Geert > -- Derek Atkins 617-623-3745 de...@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: r21768 - gnucash/branches/2.4/packaging/win32 - More changes to compile gtk-2.24.
Op woensdag 28 december 2011 09:09:05 schreef Derek Atkins: > Hi, > > On Wed, December 28, 2011 8:36 am, Geert Janssens wrote: > > Op dinsdag 27 december 2011 22:09:51 schreef John Ralls: > >> So with the changes checked in (and a reset.sh), it should build a > >> working > >> package... at least, it does here. > > > > I wanted to perform the reset.sh, but at this time the connection to the > > build > > server fails. > > > > Unless Derek does it first, I'll try again later. > > It looks like the vmware management interface crashed. (I really need to > look into a new/better VM hosting solution, considering vmware-server was > EOLed in June). I restarted the management interface so now it should > connect. > Thanks > I've run reset.sh from /c/soft-2,4/packaging. Is there somewhere else it > needs to be run? > I would start the weekly_build.sh script in the same directory, to get an intermediate build to look at. Otherwise we'll have to wait until tomorrow. Geert ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: r21768 - gnucash/branches/2.4/packaging/win32 - More changes to compile gtk-2.24.
Hi, On Wed, December 28, 2011 8:36 am, Geert Janssens wrote: > Op dinsdag 27 december 2011 22:09:51 schreef John Ralls: >> So with the changes checked in (and a reset.sh), it should build a >> working >> package... at least, it does here. >> > I wanted to perform the reset.sh, but at this time the connection to the > build > server fails. > > Unless Derek does it first, I'll try again later. It looks like the vmware management interface crashed. (I really need to look into a new/better VM hosting solution, considering vmware-server was EOLed in June). I restarted the management interface so now it should connect. I've run reset.sh from /c/soft-2,4/packaging. Is there somewhere else it needs to be run? > Geert -derek -- Derek Atkins 617-623-3745 de...@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: r21768 - gnucash/branches/2.4/packaging/win32 - More changes to compile gtk-2.24.
Op dinsdag 27 december 2011 22:09:51 schreef John Ralls: > Jeez, you guys give up *way* too easily! ;-) > I'm glad you're more persistent! ;-) > The problem with SLib turns out to be a Guile bug: ice-9/boot-9/load-modules > determines a absolute path isn't portable, which is why we were seeing the > "double" paths. The easy fix is a one-liner. I'd file a bug, but "Submit" > is crossed off in the menu, so to hell with them. (The problem may or may > not exist in 2.0; the code is totally different, so I can't tell without > testing, and I'm not going to take time now to do that.) > > I'd mis-diagnosed the libxml problem, too. After I got past the SLib issue > and got a dist made, I had the same symbols problem again. This turns out > to be a disconnect between install-impl.sh and dist-impl.sh: Install builds > libxml2 from source for Gnome, and dist used a downloaded binary. That > isn't going to work. > > So with the changes checked in (and a reset.sh), it should build a working > package... at least, it does here. > I wanted to perform the reset.sh, but at this time the connection to the build server fails. Unless Derek does it first, I'll try again later. Geert ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: r21768 - gnucash/branches/2.4/packaging/win32 - More changes to compile gtk-2.24.
On Dec 27, 2011, at 1:57 PM, Christian Stimming wrote: > Am Dienstag, 27. Dezember 2011, 22:51:46 schrieb Geert Janssens: >>> There is enough goofiness with MinGW GCC 4.4.0 that I couldn't get it to >>> link properly in a couple of places, and the one that ultimately kicked >>> my butt was libgsf->libxml2, where the linker won't accept that >>> xmlGenericError actually *is* exported, even though several other >>> libraries link it just fine. > > My first thought was that there might be multiple libxml2.dll somewhere in > the > various packages (such as one from gnome or ourselves and another one in > ActivePerl, or similar). But I guess you've already checked for those. > >>> So I spent a couple of (partial) days with GCC 4.5 guile 1.8.7. No joy >>> (and this won't be any surprise to Geert) because Slib has an issue >>> with its load path. It sure looks to me like Guile treats paths >>> differently under Win32 than under Darwin & Linux, because (use-modules >>> (ice-9 slib)) works fine in the latter and fails with a duplicated path >>> in the former. I'm very much a Scheme/Guile noob, though, so I'm very >>> likely missing the real problem. I can't even add (write) calls to get >>> guile.init to tell me where it's going astray. >>> >>> So at this point I'm not sure where to go. It's tempting indeed to say >>> that Geert should just backport the changes that got rid of SLib: >>> They're not likely to be central to anything besides reports -- and >>> besides, they're known to mostly work. OTOH, it seems risky to >>> introduce a significant change right before a release... so how >>> significant are the changes? >> >> I'm very sorry GCC 4.4 didn't work out. I had really hoped I didn't succeed >> because my knowledge of the build system was too limited, but clearly there >> are other issues. >> >> While you were at it, I already silently tried to backport all guile 1.8.8 >> related changes to 2.4, but that didn't succeed either. I probably still >> missed some commits. >> >> This continues to show what a hornet's nest the depedencies on Windows are. >> >> At this point I'm actually more inclined to go for plan B, forget the >> dependency updates on 2.4 and instead focus on getting 2.6 ready and with >> aqbanking 5. > > I can't add any wisdom as well. Concerning the errors the two of you are > reporting, I also don't have any further idea. > > Hence, in order to get a new release up and running, I would indeed also vote > for getting a 2.5/2.6 version ready in the rather near future, instead of > trying other random bits with the 2.4 branch. Of course, if anyone still > finds > out what's wrong with the current 2.4 build, this would be fine as well, but > on the other hand investing one's time in the new branch is probably the more > future-proof investment of time... Jeez, you guys give up *way* too easily! ;-) The problem with SLib turns out to be a Guile bug: ice-9/boot-9/load-modules determines a absolute path isn't portable, which is why we were seeing the "double" paths. The easy fix is a one-liner. I'd file a bug, but "Submit" is crossed off in the menu, so to hell with them. (The problem may or may not exist in 2.0; the code is totally different, so I can't tell without testing, and I'm not going to take time now to do that.) I'd mis-diagnosed the libxml problem, too. After I got past the SLib issue and got a dist made, I had the same symbols problem again. This turns out to be a disconnect between install-impl.sh and dist-impl.sh: Install builds libxml2 from source for Gnome, and dist used a downloaded binary. That isn't going to work. So with the changes checked in (and a reset.sh), it should build a working package... at least, it does here. It's still not quite ready for release: Gnucash isn't noticing that AQB is present. But it's bedtime now, and tomorrow's Habitat. Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: r21768 - gnucash/branches/2.4/packaging/win32 - More changes to compile gtk-2.24.
Am Dienstag, 27. Dezember 2011, 22:51:46 schrieb Geert Janssens: > > There is enough goofiness with MinGW GCC 4.4.0 that I couldn't get it to > > link properly in a couple of places, and the one that ultimately kicked > > my butt was libgsf->libxml2, where the linker won't accept that > > xmlGenericError actually *is* exported, even though several other > > libraries link it just fine. My first thought was that there might be multiple libxml2.dll somewhere in the various packages (such as one from gnome or ourselves and another one in ActivePerl, or similar). But I guess you've already checked for those. > > So I spent a couple of (partial) days with GCC 4.5 guile 1.8.7. No joy > > (and this won't be any surprise to Geert) because Slib has an issue > > with its load path. It sure looks to me like Guile treats paths > > differently under Win32 than under Darwin & Linux, because (use-modules > > (ice-9 slib)) works fine in the latter and fails with a duplicated path > > in the former. I'm very much a Scheme/Guile noob, though, so I'm very > > likely missing the real problem. I can't even add (write) calls to get > > guile.init to tell me where it's going astray. > > > > So at this point I'm not sure where to go. It's tempting indeed to say > > that Geert should just backport the changes that got rid of SLib: > > They're not likely to be central to anything besides reports -- and > > besides, they're known to mostly work. OTOH, it seems risky to > > introduce a significant change right before a release... so how > > significant are the changes? > > I'm very sorry GCC 4.4 didn't work out. I had really hoped I didn't succeed > because my knowledge of the build system was too limited, but clearly there > are other issues. > > While you were at it, I already silently tried to backport all guile 1.8.8 > related changes to 2.4, but that didn't succeed either. I probably still > missed some commits. > > This continues to show what a hornet's nest the depedencies on Windows are. > > At this point I'm actually more inclined to go for plan B, forget the > dependency updates on 2.4 and instead focus on getting 2.6 ready and with > aqbanking 5. I can't add any wisdom as well. Concerning the errors the two of you are reporting, I also don't have any further idea. Hence, in order to get a new release up and running, I would indeed also vote for getting a 2.5/2.6 version ready in the rather near future, instead of trying other random bits with the 2.4 branch. Of course, if anyone still finds out what's wrong with the current 2.4 build, this would be fine as well, but on the other hand investing one's time in the new branch is probably the more future-proof investment of time... Regards, Christian ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: r21768 - gnucash/branches/2.4/packaging/win32 - More changes to compile gtk-2.24.
Op dinsdag 27 december 2011 00:18:46 schreef John Ralls: > Well, that didn't actually work out. > > There is enough goofiness with MinGW GCC 4.4.0 that I couldn't get it to > link properly in a couple of places, and the one that ultimately kicked my > butt was libgsf->libxml2, where the linker won't accept that > xmlGenericError actually *is* exported, even though several other libraries > link it just fine. > > So I spent a couple of (partial) days with GCC 4.5 guile 1.8.7. No joy (and > this won't be any surprise to Geert) because Slib has an issue with its > load path. It sure looks to me like Guile treats paths differently under > Win32 than under Darwin & Linux, because (use-modules (ice-9 slib)) works > fine in the latter and fails with a duplicated path in the former. I'm very > much a Scheme/Guile noob, though, so I'm very likely missing the real > problem. I can't even add (write) calls to get guile.init to tell me where > it's going astray. > > So at this point I'm not sure where to go. It's tempting indeed to say that > Geert should just backport the changes that got rid of SLib: They're not > likely to be central to anything besides reports -- and besides, they're > known to mostly work. OTOH, it seems risky to introduce a significant > change right before a release... so how significant are the changes? > Hi John, I'm very sorry GCC 4.4 didn't work out. I had really hoped I didn't succeed because my knowledge of the build system was too limited, but clearly there are other issues. While you were at it, I already silently tried to backport all guile 1.8.8 related changes to 2.4, but that didn't succeed either. I probably still missed some commits. This continues to show what a hornet's nest the depedencies on Windows are. At this point I'm actually more inclined to go for plan B, forget the dependency updates on 2.4 and instead focus on getting 2.6 ready and with aqbanking 5. Geert ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: r21768 - gnucash/branches/2.4/packaging/win32 - More changes to compile gtk-2.24.
On Dec 24, 2011, at 11:37 AM, John Ralls wrote: > > On Dec 24, 2011, at 9:02 AM, Geert Janssens wrote: > >> Op zaterdag 24 december 2011 08:06:28 schreef John Ralls: >>> On Dec 24, 2011, at 6:04 AM, Geert Janssens wrote: Op vrijdag 23 december 2011 21:45:02 schreef John Ralls: > On Dec 22, 2011, at 11:07 PM, John Ralls wrote: >> This produced a problem with gettext, but it's too late to >> investigate >> tonight. I'll have a look at it in the morning. > > After a bit of a struggle with gettext, goffice, and openSP > (mismatched > compiler for the binaries of gettext-0.18.1.1-2, but 0.18.1.1-1 works; > goffice-0.7 uses a Gtk class that's supposed to be deprecated in > Gtk-2.24 but seems to be removed, and the C++ packaging of mingw > libstdc++ was screwed up), I got a build all the way through most of > Gnucash (it failed to set up a gconf directory in gnucash-2.4/inst). > Close enough to commit today's work and see what happens on the > nightly, so I did. Thanks for your debugging efforts. The nightly build failed at mingw already. But I assume this is normal as you changed the gcc version. I have run a reset.sh on the server to start with a clean environment and started another build. This is running now, we'll see what the result will be. >>> >>> Great, thanks. >>> >>> Is there a way to tell the buildbot to run reset.sh without a) shell access >>> or b) adding it at the top of install.sh? >>> >> Not that I know of. >> >> The build is now compiling the GnuCash sources, so it's proceeding nicely. >> >> I won't be available anymore from now on until probably Tuesday. So if more >> actions are needed on the build server, either someone else will have to >> take >> over or it'll have to wait until Tuesday. >> >> In any case, >> >> Merry Christmass to all. > > Well, it built, but it doesn't work. First, it couldn't find libgdk-pixbuf > because I hadn't adjusted dist-impl.sh to include it. Next, it can't find an > "entry point" (xmlGenericError) from libxml2. > > I've worked around my install problem from last night (just needed to delete > the inst directory and try again), so I'll try to get the last few issues > sorted today. Well, that didn't actually work out. There is enough goofiness with MinGW GCC 4.4.0 that I couldn't get it to link properly in a couple of places, and the one that ultimately kicked my butt was libgsf->libxml2, where the linker won't accept that xmlGenericError actually *is* exported, even though several other libraries link it just fine. So I spent a couple of (partial) days with GCC 4.5 guile 1.8.7. No joy (and this won't be any surprise to Geert) because Slib has an issue with its load path. It sure looks to me like Guile treats paths differently under Win32 than under Darwin & Linux, because (use-modules (ice-9 slib)) works fine in the latter and fails with a duplicated path in the former. I'm very much a Scheme/Guile noob, though, so I'm very likely missing the real problem. I can't even add (write) calls to get guile.init to tell me where it's going astray. So at this point I'm not sure where to go. It's tempting indeed to say that Geert should just backport the changes that got rid of SLib: They're not likely to be central to anything besides reports -- and besides, they're known to mostly work. OTOH, it seems risky to introduce a significant change right before a release... so how significant are the changes? Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: r21768 - gnucash/branches/2.4/packaging/win32 - More changes to compile gtk-2.24.
On Dec 24, 2011, at 9:02 AM, Geert Janssens wrote: > Op zaterdag 24 december 2011 08:06:28 schreef John Ralls: >> On Dec 24, 2011, at 6:04 AM, Geert Janssens wrote: >>> Op vrijdag 23 december 2011 21:45:02 schreef John Ralls: On Dec 22, 2011, at 11:07 PM, John Ralls wrote: > This produced a problem with gettext, but it's too late to > investigate > tonight. I'll have a look at it in the morning. After a bit of a struggle with gettext, goffice, and openSP (mismatched compiler for the binaries of gettext-0.18.1.1-2, but 0.18.1.1-1 works; goffice-0.7 uses a Gtk class that's supposed to be deprecated in Gtk-2.24 but seems to be removed, and the C++ packaging of mingw libstdc++ was screwed up), I got a build all the way through most of Gnucash (it failed to set up a gconf directory in gnucash-2.4/inst). Close enough to commit today's work and see what happens on the nightly, so I did. >>> >>> Thanks for your debugging efforts. >>> >>> The nightly build failed at mingw already. But I assume this is normal >>> as you changed the gcc version. I have run a reset.sh on the server to >>> start with a clean environment and started another build. This is >>> running now, we'll see what the result will be. >> >> Great, thanks. >> >> Is there a way to tell the buildbot to run reset.sh without a) shell access >> or b) adding it at the top of install.sh? >> > Not that I know of. > > The build is now compiling the GnuCash sources, so it's proceeding nicely. > > I won't be available anymore from now on until probably Tuesday. So if more > actions are needed on the build server, either someone else will have to take > over or it'll have to wait until Tuesday. > > In any case, > > Merry Christmass to all. Well, it built, but it doesn't work. First, it couldn't find libgdk-pixbuf because I hadn't adjusted dist-impl.sh to include it. Next, it can't find an "entry point" (xmlGenericError) from libxml2. I've worked around my install problem from last night (just needed to delete the inst directory and try again), so I'll try to get the last few issues sorted today. Thanks for the help, and Merry Christmas. Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: r21768 - gnucash/branches/2.4/packaging/win32 - More changes to compile gtk-2.24.
Op zaterdag 24 december 2011 08:06:28 schreef John Ralls: > On Dec 24, 2011, at 6:04 AM, Geert Janssens wrote: > > Op vrijdag 23 december 2011 21:45:02 schreef John Ralls: > >> On Dec 22, 2011, at 11:07 PM, John Ralls wrote: > >>> This produced a problem with gettext, but it's too late to > >>> investigate > >>> tonight. I'll have a look at it in the morning. > >> > >> After a bit of a struggle with gettext, goffice, and openSP > >> (mismatched > >> compiler for the binaries of gettext-0.18.1.1-2, but 0.18.1.1-1 works; > >> goffice-0.7 uses a Gtk class that's supposed to be deprecated in > >> Gtk-2.24 but seems to be removed, and the C++ packaging of mingw > >> libstdc++ was screwed up), I got a build all the way through most of > >> Gnucash (it failed to set up a gconf directory in gnucash-2.4/inst). > >> Close enough to commit today's work and see what happens on the > >> nightly, so I did. > > > > Thanks for your debugging efforts. > > > > The nightly build failed at mingw already. But I assume this is normal > > as you changed the gcc version. I have run a reset.sh on the server to > > start with a clean environment and started another build. This is > > running now, we'll see what the result will be. > > Great, thanks. > > Is there a way to tell the buildbot to run reset.sh without a) shell access > or b) adding it at the top of install.sh? > Not that I know of. The build is now compiling the GnuCash sources, so it's proceeding nicely. I won't be available anymore from now on until probably Tuesday. So if more actions are needed on the build server, either someone else will have to take over or it'll have to wait until Tuesday. In any case, Merry Christmass to all. Geert ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: r21768 - gnucash/branches/2.4/packaging/win32 - More changes to compile gtk-2.24.
On Dec 24, 2011, at 6:04 AM, Geert Janssens wrote: > Op vrijdag 23 december 2011 21:45:02 schreef John Ralls: >> On Dec 22, 2011, at 11:07 PM, John Ralls wrote: >>> This produced a problem with gettext, but it's too late to investigate >>> tonight. I'll have a look at it in the morning. >> After a bit of a struggle with gettext, goffice, and openSP (mismatched >> compiler for the binaries of gettext-0.18.1.1-2, but 0.18.1.1-1 works; >> goffice-0.7 uses a Gtk class that's supposed to be deprecated in Gtk-2.24 >> but seems to be removed, and the C++ packaging of mingw libstdc++ was >> screwed up), I got a build all the way through most of Gnucash (it failed >> to set up a gconf directory in gnucash-2.4/inst). Close enough to commit >> today's work and see what happens on the nightly, so I did. >> > Thanks for your debugging efforts. > > The nightly build failed at mingw already. But I assume this is normal as you > changed the gcc version. I have run a reset.sh on the server to start with a > clean environment and started another build. This is running now, we'll see > what the result will be. Great, thanks. Is there a way to tell the buildbot to run reset.sh without a) shell access or b) adding it at the top of install.sh? Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: r21768 - gnucash/branches/2.4/packaging/win32 - More changes to compile gtk-2.24.
Op vrijdag 23 december 2011 21:45:02 schreef John Ralls: > On Dec 22, 2011, at 11:07 PM, John Ralls wrote: > > This produced a problem with gettext, but it's too late to investigate > > tonight. I'll have a look at it in the morning. > After a bit of a struggle with gettext, goffice, and openSP (mismatched > compiler for the binaries of gettext-0.18.1.1-2, but 0.18.1.1-1 works; > goffice-0.7 uses a Gtk class that's supposed to be deprecated in Gtk-2.24 > but seems to be removed, and the C++ packaging of mingw libstdc++ was > screwed up), I got a build all the way through most of Gnucash (it failed > to set up a gconf directory in gnucash-2.4/inst). Close enough to commit > today's work and see what happens on the nightly, so I did. > Thanks for your debugging efforts. The nightly build failed at mingw already. But I assume this is normal as you changed the gcc version. I have run a reset.sh on the server to start with a clean environment and started another build. This is running now, we'll see what the result will be. Geert ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: r21768 - gnucash/branches/2.4/packaging/win32 - More changes to compile gtk-2.24.
On Dec 22, 2011, at 11:07 PM, John Ralls wrote: > > On Dec 22, 2011, at 3:28 PM, John Ralls wrote: > >> >> On Dec 21, 2011, at 9:44 AM, Geert Janssens wrote: >> >>> On 21-12-11 15:43, John Ralls wrote: I got an msys-1.0.11 installation working on my windows VM yesterday and got it to go as far as starting Gnucash (I have a link error that I think is left over from the weekend and a completely different setup using the latest mingw -- which didn't go away when I cleaned gnome, gwen and aqb, so I think I need to start over with a clean tree). Unfortunately the 2.4 build bombed on gwen with an error that I don't immediately understand. I'm not likely to have time to dig into that today, so if you can fix the gwen error, great. Otherwise, I think you should revert your change to custom.sh yesterday (so that it goes back to aqb4) and we'll see what happens on tonight's build. If we have to bump guile to 1.8, that should still be OK. 2.4 does work with 1.8, that's what ships on OSX. Regards, John Ralls >>> The gwenhywfar bomb was actually a mingw build failure. However, when >>> install.sh fails, dist.sh is started immediately without any check if >>> install.sh finished successfully. (The windows build system really is that >>> ugly). >>> >>> Since gwen isn't built yet, dist.sh fails in copying its files. >>> >>> I think mingw fails because the old directory was still around. To fix >>> this, I have chosen to run reset.sh first in order to get a clean build >>> environment and have manually started a 2.4 build. We'll see what the >>> result will be now. >>> >>> Regarding the guile update: if it were only the guile package that had to >>> be replaced it would be no problem. However, I never managed to build the >>> slib library for guile 1.8 on windows. So in trunk I have applied a series >>> of patches (once provided by Andy Wingo) to eliminate slib. So updating >>> guile on the 2.4 branch means we also have to apply this set of patches to >>> GnuCash 2.4. Is that ok for the stable branch ? >> >> I think it's probably easier at this point to try to stay with guile-1.6.7 >> for 2.4. >> >> I found that the error message maps to https://savannah.gnu.org/bugs/?29583, >> which was against 1.8.6 when compiled with gcc-4.5. I first tried applying >> the patch (provided by that same Andy Wingo). While it applied fine, it >> didn't fix the problem. Now I'm trying to get gcc-4.4 to work, but I'm >> having a dinner party tonight and I don't know if I'll get it done until >> tomorrow. > > This produced a problem with gettext, but it's too late to investigate > tonight. I'll have a look at it in the morning. > After a bit of a struggle with gettext, goffice, and openSP (mismatched compiler for the binaries of gettext-0.18.1.1-2, but 0.18.1.1-1 works; goffice-0.7 uses a Gtk class that's supposed to be deprecated in Gtk-2.24 but seems to be removed, and the C++ packaging of mingw libstdc++ was screwed up), I got a build all the way through most of Gnucash (it failed to set up a gconf directory in gnucash-2.4/inst). Close enough to commit today's work and see what happens on the nightly, so I did. Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: r21768 - gnucash/branches/2.4/packaging/win32 - More changes to compile gtk-2.24.
On Dec 22, 2011, at 3:28 PM, John Ralls wrote: > > On Dec 21, 2011, at 9:44 AM, Geert Janssens wrote: > >> On 21-12-11 15:43, John Ralls wrote: >>> I got an msys-1.0.11 installation working on my windows VM yesterday and >>> got it to go as far as starting Gnucash (I have a link error that I think >>> is left over from the weekend and a completely different setup using the >>> latest mingw -- which didn't go away when I cleaned gnome, gwen and aqb, so >>> I think I need to start over with a clean tree). Unfortunately the 2.4 >>> build bombed on gwen with an error that I don't immediately understand. >>> >>> I'm not likely to have time to dig into that today, so if you can fix the >>> gwen error, great. Otherwise, I think you should revert your change to >>> custom.sh yesterday (so that it goes back to aqb4) and we'll see what >>> happens on tonight's build. >>> >>> If we have to bump guile to 1.8, that should still be OK. 2.4 does work >>> with 1.8, that's what ships on OSX. >>> >>> Regards, >>> John Ralls >>> >> The gwenhywfar bomb was actually a mingw build failure. However, when >> install.sh fails, dist.sh is started immediately without any check if >> install.sh finished successfully. (The windows build system really is that >> ugly). >> >> Since gwen isn't built yet, dist.sh fails in copying its files. >> >> I think mingw fails because the old directory was still around. To fix this, >> I have chosen to run reset.sh first in order to get a clean build >> environment and have manually started a 2.4 build. We'll see what the result >> will be now. >> >> Regarding the guile update: if it were only the guile package that had to be >> replaced it would be no problem. However, I never managed to build the slib >> library for guile 1.8 on windows. So in trunk I have applied a series of >> patches (once provided by Andy Wingo) to eliminate slib. So updating guile >> on the 2.4 branch means we also have to apply this set of patches to GnuCash >> 2.4. Is that ok for the stable branch ? > > I think it's probably easier at this point to try to stay with guile-1.6.7 > for 2.4. > > I found that the error message maps to https://savannah.gnu.org/bugs/?29583, > which was against 1.8.6 when compiled with gcc-4.5. I first tried applying > the patch (provided by that same Andy Wingo). While it applied fine, it > didn't fix the problem. Now I'm trying to get gcc-4.4 to work, but I'm having > a dinner party tonight and I don't know if I'll get it done until tomorrow. This produced a problem with gettext, but it's too late to investigate tonight. I'll have a look at it in the morning. Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: r21768 - gnucash/branches/2.4/packaging/win32 - More changes to compile gtk-2.24.
On Dec 21, 2011, at 9:44 AM, Geert Janssens wrote: > On 21-12-11 15:43, John Ralls wrote: >> I got an msys-1.0.11 installation working on my windows VM yesterday and got >> it to go as far as starting Gnucash (I have a link error that I think is >> left over from the weekend and a completely different setup using the latest >> mingw -- which didn't go away when I cleaned gnome, gwen and aqb, so I think >> I need to start over with a clean tree). Unfortunately the 2.4 build bombed >> on gwen with an error that I don't immediately understand. >> >> I'm not likely to have time to dig into that today, so if you can fix the >> gwen error, great. Otherwise, I think you should revert your change to >> custom.sh yesterday (so that it goes back to aqb4) and we'll see what >> happens on tonight's build. >> >> If we have to bump guile to 1.8, that should still be OK. 2.4 does work with >> 1.8, that's what ships on OSX. >> >> Regards, >> John Ralls >> > The gwenhywfar bomb was actually a mingw build failure. However, when > install.sh fails, dist.sh is started immediately without any check if > install.sh finished successfully. (The windows build system really is that > ugly). > > Since gwen isn't built yet, dist.sh fails in copying its files. > > I think mingw fails because the old directory was still around. To fix this, > I have chosen to run reset.sh first in order to get a clean build environment > and have manually started a 2.4 build. We'll see what the result will be now. > > Regarding the guile update: if it were only the guile package that had to be > replaced it would be no problem. However, I never managed to build the slib > library for guile 1.8 on windows. So in trunk I have applied a series of > patches (once provided by Andy Wingo) to eliminate slib. So updating guile on > the 2.4 branch means we also have to apply this set of patches to GnuCash > 2.4. Is that ok for the stable branch ? I think it's probably easier at this point to try to stay with guile-1.6.7 for 2.4. I found that the error message maps to https://savannah.gnu.org/bugs/?29583, which was against 1.8.6 when compiled with gcc-4.5. I first tried applying the patch (provided by that same Andy Wingo). While it applied fine, it didn't fix the problem. Now I'm trying to get gcc-4.4 to work, but I'm having a dinner party tonight and I don't know if I'll get it done until tomorrow. Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: r21768 - gnucash/branches/2.4/packaging/win32 - More changes to compile gtk-2.24.
On 21-12-11 18:44, Geert Janssens wrote: On 21-12-11 15:43, John Ralls wrote: I got an msys-1.0.11 installation working on my windows VM yesterday and got it to go as far as starting Gnucash (I have a link error that I think is left over from the weekend and a completely different setup using the latest mingw -- which didn't go away when I cleaned gnome, gwen and aqb, so I think I need to start over with a clean tree). Unfortunately the 2.4 build bombed on gwen with an error that I don't immediately understand. I'm not likely to have time to dig into that today, so if you can fix the gwen error, great. Otherwise, I think you should revert your change to custom.sh yesterday (so that it goes back to aqb4) and we'll see what happens on tonight's build. If we have to bump guile to 1.8, that should still be OK. 2.4 does work with 1.8, that's what ships on OSX. Regards, John Ralls The gwenhywfar bomb was actually a mingw build failure. However, when install.sh fails, dist.sh is started immediately without any check if install.sh finished successfully. (The windows build system really is that ugly). Since gwen isn't built yet, dist.sh fails in copying its files. I think mingw fails because the old directory was still around. To fix this, I have chosen to run reset.sh first in order to get a clean build environment and have manually started a 2.4 build. We'll see what the result will be now. Regarding the guile update: if it were only the guile package that had to be replaced it would be no problem. However, I never managed to build the slib library for guile 1.8 on windows. So in trunk I have applied a series of patches (once provided by Andy Wingo) to eliminate slib. So updating guile on the 2.4 branch means we also have to apply this set of patches to GnuCash 2.4. Is that ok for the stable branch ? Geert Hmm, as I expected, the 2.4 build failed on guile. I don't have time tonight anymore and I would like to hear other's opinions on my earlier question before I want to go forward with this anyway. Is it ok/worth it to apply all the guile 1.8 patches in GnuCash 2.4 (not only in the windows build system) in order to get the 2.4 build on windows working with aqbanking 5 ? For reference most of these patches were applied to the trunk branch right after 2.4 was branched. Geert ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: r21768 - gnucash/branches/2.4/packaging/win32 - More changes to compile gtk-2.24.
On Dec 21, 2011, at 1:02 AM, Geert Janssens wrote: > On 21-12-11 03:28, John Ralls wrote: >> Author: jralls >> Date: 2011-12-20 21:28:48 -0500 (Tue, 20 Dec 2011) >> New Revision: 21768 >> Trac: http://svn.gnucash.org/trac/changeset/21768 >> >> Modified: >>gnucash/branches/2.4/packaging/win32/defaults.sh >>gnucash/branches/2.4/packaging/win32/install-impl.sh >> Log: >> More changes to compile gtk-2.24. >> >> >> Cross your fingers! >> >> Modified: gnucash/branches/2.4/packaging/win32/defaults.sh >> === >> --- gnucash/branches/2.4/packaging/win32/defaults.sh 2011-12-20 21:12:22 UTC >> (rev 21767) >> +++ gnucash/branches/2.4/packaging/win32/defaults.sh 2011-12-21 02:28:48 UTC >> (rev 21768) >> @@ -78,11 +78,24 @@ >> set_default DTK_URL "$SF_MIRROR/mingw/msysDTK-1.0.1.exe" >> set_default M4_URL "$SF_MIRROR/mingw/m4-1.4.7-MSYS.tar.bz2" >> >> -set_default MINGW_RT_URL "$SF_MIRROR/mingw/mingwrt-3.15.1-mingw32.tar.gz" >> -set_default W32API_URL "$SF_MIRROR/mingw/w32api-3.13-mingw32-dev.tar.gz" >> +set_default MINGW_RT_URL "$SF_MIRROR/mingw/mingwrt-3.18-mingw32-dev.tar.gz" >> +set_default MINGW_RT_DLL_URL >> "$SF_MIRROR/mingw/mingwrt-3.18-mingw32-dll.tar.gz" >> +set_default W32API_URL "$SF_MIRROR/mingw/w32api-3.15-1-mingw32-dev.tar.lzma" >> set_default MINGW_MAKE_URL >> "$SF_MIRROR/mingw/mingw32-make-3.81-20080326-3.tar.gz" >> set_default MINGW_DIR $GLOBAL_DIR\\mingw >> >> +# The URLs for precompiled gcc/mingw binaries >> +set_default BINUTILS_URL >> "$SF_MIRROR/mingw/binutils-2.21-2-mingw32-bin.tar.lzma" >> +set_default GCC_CORE_URL >> "$SF_MIRROR/mingw/gcc-core-4.5.2-1-mingw32-bin.tar.lzma" >> +set_default GCC_CORE_DLL_URL >> "$SF_MIRROR/mingw/libgcc-4.5.2-1-mingw32-dll-1.tar.lzma" >> +set_default GCC_GPP_URL >> "$SF_MIRROR/mingw/gcc-c++-4.5.2-1-mingw32-bin.tar.lzma" >> +set_default GCC_GPP_DLL_URL >> "$SF_MIRROR/mingw/libstdc++-4.5.2-1-mingw32-dll-6.tar.lzma" >> +set_default GCC_GPP_PATCH "`pwd`/gcc-c++-4.4.0.patch" >> +set_default GCC_MPC_URL >> "$SF_MIRROR/mingw/libmpc-0.8.1-1-mingw32-dll-2.tar.lzma" >> +set_default GCC_MPFR_URL >> "$SF_MIRROR/mingw/libmpfr-2.4.1-1-mingw32-dll-1.tar.lzma" >> +set_default GCC_GMP_URL >> "$SF_MIRROR/mingw/libgmp-5.0.1-1-mingw32-dll-10.tar.lzma" >> +set_default GCC_PTHREADS_URL >> "$SF_MIRROR/mingw/libpthread-2.8.0-3-mingw32-dll-2.tar.lzma" >> + > Hmm, I suspect that if you need to update the gcc version to get by, we'll be > in for a long run. I remember having a lot of issues with gcc 4.5.2 and > guile 1.6 in the Windows native build. That's why I updated gcc and guile at > the same time in trunk. > I got an msys-1.0.11 installation working on my windows VM yesterday and got it to go as far as starting Gnucash (I have a link error that I think is left over from the weekend and a completely different setup using the latest mingw -- which didn't go away when I cleaned gnome, gwen and aqb, so I think I need to start over with a clean tree). Unfortunately the 2.4 build bombed on gwen with an error that I don't immediately understand. I'm not likely to have time to dig into that today, so if you can fix the gwen error, great. Otherwise, I think you should revert your change to custom.sh yesterday (so that it goes back to aqb4) and we'll see what happens on tonight's build. If we have to bump guile to 1.8, that should still be OK. 2.4 does work with 1.8, that's what ships on OSX. Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: r21768 - gnucash/branches/2.4/packaging/win32 - More changes to compile gtk-2.24.
On 21-12-11 03:28, John Ralls wrote: Author: jralls Date: 2011-12-20 21:28:48 -0500 (Tue, 20 Dec 2011) New Revision: 21768 Trac: http://svn.gnucash.org/trac/changeset/21768 Modified: gnucash/branches/2.4/packaging/win32/defaults.sh gnucash/branches/2.4/packaging/win32/install-impl.sh Log: More changes to compile gtk-2.24. Cross your fingers! Modified: gnucash/branches/2.4/packaging/win32/defaults.sh === --- gnucash/branches/2.4/packaging/win32/defaults.sh2011-12-20 21:12:22 UTC (rev 21767) +++ gnucash/branches/2.4/packaging/win32/defaults.sh2011-12-21 02:28:48 UTC (rev 21768) @@ -78,11 +78,24 @@ set_default DTK_URL "$SF_MIRROR/mingw/msysDTK-1.0.1.exe" set_default M4_URL "$SF_MIRROR/mingw/m4-1.4.7-MSYS.tar.bz2" -set_default MINGW_RT_URL "$SF_MIRROR/mingw/mingwrt-3.15.1-mingw32.tar.gz" -set_default W32API_URL "$SF_MIRROR/mingw/w32api-3.13-mingw32-dev.tar.gz" +set_default MINGW_RT_URL "$SF_MIRROR/mingw/mingwrt-3.18-mingw32-dev.tar.gz" +set_default MINGW_RT_DLL_URL "$SF_MIRROR/mingw/mingwrt-3.18-mingw32-dll.tar.gz" +set_default W32API_URL "$SF_MIRROR/mingw/w32api-3.15-1-mingw32-dev.tar.lzma" set_default MINGW_MAKE_URL "$SF_MIRROR/mingw/mingw32-make-3.81-20080326-3.tar.gz" set_default MINGW_DIR $GLOBAL_DIR\\mingw +# The URLs for precompiled gcc/mingw binaries +set_default BINUTILS_URL "$SF_MIRROR/mingw/binutils-2.21-2-mingw32-bin.tar.lzma" +set_default GCC_CORE_URL "$SF_MIRROR/mingw/gcc-core-4.5.2-1-mingw32-bin.tar.lzma" +set_default GCC_CORE_DLL_URL "$SF_MIRROR/mingw/libgcc-4.5.2-1-mingw32-dll-1.tar.lzma" +set_default GCC_GPP_URL "$SF_MIRROR/mingw/gcc-c++-4.5.2-1-mingw32-bin.tar.lzma" +set_default GCC_GPP_DLL_URL "$SF_MIRROR/mingw/libstdc++-4.5.2-1-mingw32-dll-6.tar.lzma" +set_default GCC_GPP_PATCH "`pwd`/gcc-c++-4.4.0.patch" +set_default GCC_MPC_URL "$SF_MIRROR/mingw/libmpc-0.8.1-1-mingw32-dll-2.tar.lzma" +set_default GCC_MPFR_URL "$SF_MIRROR/mingw/libmpfr-2.4.1-1-mingw32-dll-1.tar.lzma" +set_default GCC_GMP_URL "$SF_MIRROR/mingw/libgmp-5.0.1-1-mingw32-dll-10.tar.lzma" +set_default GCC_PTHREADS_URL "$SF_MIRROR/mingw/libpthread-2.8.0-3-mingw32-dll-2.tar.lzma" + Hmm, I suspect that if you need to update the gcc version to get by, we'll be in for a long run. I remember having a lot of issues with gcc 4.5.2 and guile 1.6 in the Windows native build. That's why I updated gcc and guile at the same time in trunk. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
