On May 29, 2014, at 10:11 AM, Wm Tarr wrote:
> On 15/05/2014 23:16, Wm Tarr wrote:
>>
>> My compile with enable-python is clean but the resulting .exe doesn't work,
>> or rather, it doesn't work for long.
>>
>> trace logs are like this
>> ===
>> * 21:34:24 INFO [main] System locale returned
On 15/05/2014 23:16, Wm Tarr wrote:
My compile with enable-python is clean but the resulting .exe doesn't
work, or rather, it doesn't work for long.
trace logs are like this
===
* 21:34:24 INFO [main] System locale returned
English_United Kingdom.1252
* 21:34:24 INFO [main] Effective loc
On 14/05/2014 00:42, Wm Tarr wrote:
[ff to self]
1. there is a conflict between gcdev\gnucash\build\config.h and
Python27\include\pyconfig.h
2. More seriously (and I think recently introduced) is a duplicate
variable (I didn't make a note of the error msg) between
Those are still outs
On 10/05/2014 10:36, Geert Janssens wrote:
On Friday 09 May 2014 16:51:06 Wm Tarr wrote:
I'm working my way through getting python enabled with "Windows from
scratch".
Great ! Will you document your success ?
When it happens, definitely. Made a lot of progress today, I can do an
error fre
On Friday 09 May 2014 16:51:06 Wm Tarr wrote:
> I'm working my way through getting python enabled with "Windows from
> scratch".
>
Great ! Will you document your success ?
> Before anyone gets too excited it is early days but building on
> Geert's work makes a lot more sense than previous methods
On May 7, 2014, at 8:54 AM, Geert Janssens wrote:
> On Friday 02 May 2014 14:55:42 John Ralls wrote:
then I get the dreaded unrecognized “l” format error,
>>>
>>> What is the dreaded unrecognized "l" format error ? I have never
>>> seen it on my WinXP test system. In which step do you get
On Friday 02 May 2014 14:55:42 John Ralls wrote:
> > > then I get the dreaded unrecognized “l” format error,
> >
> > What is the dreaded unrecognized "l" format error ? I have never
> > seen it on my WinXP test system. In which step do you get this ?
> It’s that the ancient msvcrt.dll used by MinG
On Friday 02 May 2014 14:55:42 John Ralls wrote:
> On May 2, 2014, at 1:28 PM, Geert Janssens wrote:
> > On Friday 02 May 2014 11:06:14 John Ralls wrote:
> > > The HH installation check is still failing for me, as is the
> > > installation. I ran it by hand and got it to install in c:\gcdev,
> > >
On May 2, 2014, at 1:28 PM, Geert Janssens wrote:
> On Friday 02 May 2014 11:06:14 John Ralls wrote:
> > The HH installation check is still failing for me, as is the
> > installation. I ran it by hand and got it to install in c:\gcdev, but
> > the check fails anyway:
> >
> I suspect it will fai
On Friday 02 May 2014 11:06:14 John Ralls wrote:
> The HH installation check is still failing for me, as is the
> installation. I ran it by hand and got it to install in c:\gcdev, but
> the check fails anyway:
>
I suspect it will fail because the html help install step runs pexports and
dlltool o
On May 1, 2014, at 10:21 AM, Geert Janssens wrote:
> On Thursday 01 May 2014 15:55:07 Geert Janssens wrote:
>> Thank you for my feedback. It's nice to hear my effort is appreciated.
>>
> Sometimes I appear to write utter nonsense... Rereading the above I of course
> wanted to
> say
> Thank yo
On Thursday 01 May 2014 15:55:07 Geert Janssens wrote:
> Thank you for my feedback. It's nice to hear my effort is appreciated.
>
Sometimes I appear to write utter nonsense... Rereading the above I of course
wanted to
say
Thank you for *your* feedback.
Oh well... Too many distractions...
Geert
On Thursday 01 May 2014 15:55:07 Geert Janssens wrote:
> Thank you for my feedback. It's nice to hear my effort is appreciated.
>
> Your suggestion to move the installation of html help to the top is
> very useful. I'll check if this is possible and if so will make the
> necessary changes.
>
I h
Thank you for my feedback. It's nice to hear my effort is appreciated.
Your suggestion to move the installation of html help to the top is very
useful. I'll check if this
is possible and if so will make the necessary changes.
Geert
On Tuesday 29 April 2014 20:08:59 Wm Tarr wrote:
> On 28/04/20
On Apr 29, 2014, at 1:14 PM, Wm Tarr wrote:
> On 28/04/2014 21:01, John Ralls wrote:
>> On Apr 28, 2014, at 12:27 PM, Christian Stimming
>> wrote:
>>
>>> Am Montag, 28. April 2014, 18:56:48 schrieb Geert Janssens:
> For wild, not even in the oven yet, for the very long term, how about
>>>
On 28/04/2014 21:01, John Ralls wrote:
On Apr 28, 2014, at 12:27 PM, Christian Stimming wrote:
Am Montag, 28. April 2014, 18:56:48 schrieb Geert Janssens:
For wild, not even in the oven yet, for the very long term, how about
"build GC native in MSVC"?
:
:) Would require a copy of MSVC of cou
On 28/04/2014 10:09, Geert Janssens wrote:
Lastly, how to use my repository ?
- Download the bootstrap_win_dev.vbs script. It has some documentation
at the beginning. Running it is mostly a double-click. This will prepare
a c:\gcdev directory with the minimal tools required to run install.sh
- S
On Tuesday 29 April 2014 15:34:29 Wm Tarr wrote:
> On 29/04/2014 15:16, Geert Janssens wrote:
> > On Tuesday 29 April 2014 16:05:31 Geert Janssens wrote:
> >> Thanks for testing.
> >>
> >> Svn shouldn't have been in there anymore. We're not using it for
> >> gnucash development anymore. The quicke
On 29/04/2014 15:16, Geert Janssens wrote:
On Tuesday 29 April 2014 16:05:31 Geert Janssens wrote:
Thanks for testing.
Svn shouldn't have been in there anymore. We're not using it for
gnucash development anymore. The quickest way to get past this
point
in to remove the line add_step inst_git
On Tuesday 29 April 2014 16:05:31 Geert Janssens wrote:
> Thanks for testing.
>
> Svn shouldn't have been in there anymore. We're not using it for
> gnucash development anymore. The quickest way to get past this
point
> in to remove the line add_step inst_git from install.sh
>
> I'll push a comp
Thanks for testing.
Svn shouldn't have been in there anymore. We're not using it for gnucash
development
anymore. The quickest way to get past this point in to remove the line add_step
inst_git from
install.sh
I'll push a complete fix in a minute.
Geert
On Tuesday 29 April 2014 15:01:00 Wm
On 29/04/2014 12:10, Geert Janssens wrote:
Update: with the changes pushed today the build server should be able to
create the nightly builds in the new environment. I emulated a build
server locally by running daily_build.bat on my system.
I downloaded bootstrap_win_dev.vbs earlier this aftern
Update: with the changes pushed today the build server should be able to
create the nightly builds in the new environment. I emulated a build
server locally by running daily_build.bat on my system.
Tag builds need some more work.
Regards,
Geert
___
g
On Monday 28 April 2014 14:23:55 John Ralls wrote:
> On Apr 28, 2014, at 1:10 PM, Geert Janssens wrote:
> > I don't know if you have started this already but meanwhile I found
> > a
> > couple of bugs still (I pushed my most recent fix about 45 mins
> > ago).
> >
> > You may want to pull my most
On Apr 28, 2014, at 1:10 PM, Geert Janssens wrote:
> I don't know if you have started this already but meanwhile I found a
> couple of bugs still (I pushed my most recent fix about 45 mins ago).
>
> You may want to pull my most recent changes, remove the generated
> custom.sh file and then re
On Monday 28 April 2014 07:52:03 John Ralls wrote:
> On Apr 28, 2014, at 2:09 AM, Geert Janssens wrote:
> > This weekend I have spent more time on getting the Windows build
> > running with more recent mingw compilers (gcc 4.8).
> >
> > This is a continuation of the work I have started in Decembe
On Apr 28, 2014, at 12:27 PM, Christian Stimming wrote:
> Am Montag, 28. April 2014, 18:56:48 schrieb Geert Janssens:
>>> For wild, not even in the oven yet, for the very long term, how about
>>> "build GC native in MSVC"?
>> :
>> :) Would require a copy of MSVC of course.
>
> Yeah, but this do
Am Montag, 28. April 2014, 18:56:48 schrieb Geert Janssens:
> > For wild, not even in the oven yet, for the very long term, how about
> > "build GC native in MSVC"?
> :
> :) Would require a copy of MSVC of course.
Yeah, but this doesn't have to be costly: For our purposes, the free (as in
beer) "
On Monday 28 April 2014 17:54:15 Christian Stimming wrote:
> On 28. April 2014 16:52:03 MESZ, John Ralls
wrote:
> >For wild, not even in the oven yet, for the very long term, how about
> >"build GC native in MSVC"?
>
> This isn't as weird as it sounds: I've been able to compile and run
> the cut
On Monday 28 April 2014 07:52:03 John Ralls wrote:
> On Apr 28, 2014, at 2:09 AM, Geert Janssens wrote:
> > This weekend I have spent more time on getting the Windows build
> > running with more recent mingw compilers (gcc 4.8).
> >
> > This is a continuation of the work I have started in Decembe
On 28. April 2014 16:52:03 MESZ, John Ralls wrote:
>
>For wild, not even in the oven yet, for the very long term, how about
>"build GC native in MSVC"?
This isn't as weird as it sounds: I've been able to compile and run the
cutecash experiment in msvc successfully, at the time. Hence, with cma
On Apr 28, 2014, at 2:09 AM, Geert Janssens wrote:
> This weekend I have spent more time on getting the Windows build running
> with more recent mingw compilers (gcc 4.8).
>
> This is a continuation of the work I have started in December last year.
>
> Current status:
> - I have forked packag
I just noticed I lost a few patches outside the packaging/win32
directory by setting up an independent repository. I'll add those to the
gnucash directory shortly.
Geert
On Monday 28 April 2014 11:09:39 Geert Janssens wrote:
> This weekend I have spent more time on getting the Windows build
> r
On Thursday 16 January 2014 14:26:41 Geert Janssens wrote:
> Gary,
>
> While looking at your changes I noticed you changed two lines in
> the vbs script.
>
> One is that you added my repository/branch in a comment.
> That's ok and makes it easier for others to start.
>
> The second is to install
John Ralls writes:
>> This is the "year 2037" problem, where 32-bit unsigned time rolls over.
>> However there is also a "Year 2106" problem, which is where 32-bit
>> unsigned time rolls over. I think there *are* some systems where it's
>> unsigned, but still 32 bits. Or at least there are apps
On 27/01/2014 17:20, John Ralls wrote:
On Jan 27, 2014, at 8:29 AM, Derek Atkins wrote:
Gary Bilkus writes:
Given that time_t is always a signed integer value, wouldn't
return (double)(time1-time2)
just work anyway, at least as far as a patch for mingw is concerned?
Is it always a signed
On Jan 27, 2014, at 8:29 AM, Derek Atkins wrote:
> Gary Bilkus writes:
>
>> Given that time_t is always a signed integer value, wouldn't
>>
>> return (double)(time1-time2)
>>
>> just work anyway, at least as far as a patch for mingw is concerned?
>
> Is it always a signed integer? Can't it
Gary Bilkus writes:
> Given that time_t is always a signed integer value, wouldn't
>
> return (double)(time1-time2)
>
> just work anyway, at least as far as a patch for mingw is concerned?
Is it always a signed integer? Can't it sometimes be unsigned?
This is the "year 2037" problem, where 32-
John Ralls writes:
>> Hold on though. These solutions don't call MSVCRT at all, so why
>> does that matter? And if it did, why would your solution work
>> anyway, given that sizeof is evaluated at compile time? (leaving
>> aside Derek's point that it might not compile cleanly.
They are calling
On Jan 25, 2014, at 8:09 AM, Gary Bilkus wrote:
> On 25/01/2014 15:37, John Ralls wrote:
>> On Jan 25, 2014, at 5:49 AM, Gary Bilkus wrote:
>>
>>> On 24/01/2014 17:08, Derek Atkins wrote:
John Ralls writes:
> if (sizeof(time_t) == 8)
> return (double)((int64)time1 - (int6
On 25/01/2014 15:37, John Ralls wrote:
On Jan 25, 2014, at 5:49 AM, Gary Bilkus wrote:
On 24/01/2014 17:08, Derek Atkins wrote:
John Ralls writes:
if (sizeof(time_t) == 8)
return (double)((int64)time1 - (int64)time2);
else
return (double)((int32)time1 - (int32)time2);
This code prob
On Jan 25, 2014, at 5:49 AM, Gary Bilkus wrote:
> On 24/01/2014 17:08, Derek Atkins wrote:
>> John Ralls writes:
>>
>>> if (sizeof(time_t) == 8)
>>> return (double)((int64)time1 - (int64)time2);
>>> else
>>> return (double)((int32)time1 - (int32)time2);
>> This code probably wouldn't compi
On 24/01/2014 17:08, Derek Atkins wrote:
John Ralls writes:
if (sizeof(time_t) == 8)
return (double)((int64)time1 - (int64)time2);
else
return (double)((int32)time1 - (int32)time2);
This code probably wouldn't compile cleanly. It would complain about
casting to different sizes. Even t
John Ralls writes:
> if (sizeof(time_t) == 8)
> return (double)((int64)time1 - (int64)time2);
> else
> return (double)((int32)time1 - (int32)time2);
This code probably wouldn't compile cleanly. It would complain about
casting to different sizes. Even though theoretically the compiler
shoul
On Jan 24, 2014, at 12:33 AM, Gary Bilkus wrote:
> On 23/01/2014 22:47, John Ralls wrote:
>> On Jan 23, 2014, at 7:23 AM, Gary Bilkus wrote:
>>
>>> I've done some more testing and found a problem with libofx and possibly
>>> aqbanking ( which I don't use ). It's easy enough to work round, but
On 23/01/2014 22:47, John Ralls wrote:
On Jan 23, 2014, at 7:23 AM, Gary Bilkus wrote:
I've done some more testing and found a problem with libofx and possibly
aqbanking ( which I don't use ). It's easy enough to work round, but I'm not
sure what the correct fix should be on Windows
The
On Jan 23, 2014, at 7:23 AM, Gary Bilkus wrote:
> I've done some more testing and found a problem with libofx and possibly
> aqbanking ( which I don't use ). It's easy enough to work round, but I'm not
> sure what the correct fix should be on Windows
>
>
> The problem is that there's a know
On 18/01/2014 09:53, Geert Janssens wrote:
On Friday 17 January 2014 07:30:00 John Ralls wrote:
> >
> > OK Geert,
> > I think I have what you want at
> > http://www.greenwheel.com/publicFiles/rebase-patches.zip Let me
> > know if this works for you.
> > Not being a git expert, it's possibl
On Friday 17 January 2014 07:30:00 John Ralls wrote:
> >
> > OK Geert,
> > I think I have what you want at
> > http://www.greenwheel.com/publicFiles/rebase-patches.zip Let me
> > know if this works for you.
> > Not being a git expert, it's possible I've not quite done the right
> > thing, but I th
On Jan 17, 2014, at 7:39 AM, John Ralls wrote:
>
> On Jan 16, 2014, at 7:53 AM, Geert Janssens wrote:
>
>> On Thursday 16 January 2014 07:49:53 John Ralls wrote:
>>> On Jan 16, 2014, at 5:23 AM, Geert Janssens
>>> wrote:
3. Apply your patches and ignore those that are already there is
On Jan 16, 2014, at 7:53 AM, Geert Janssens wrote:
> On Thursday 16 January 2014 07:49:53 John Ralls wrote:
> > On Jan 16, 2014, at 5:23 AM, Geert Janssens
> > wrote:
> > > 3. Apply your patches and ignore those that are already there is
> > > also correct. Then before committing anything it's
On Jan 17, 2014, at 7:30 AM, John Ralls wrote:
>
> On Jan 17, 2014, at 5:57 AM, Gary Bilkus wrote:
>
>> On 16/01/2014 13:23, Geert Janssens wrote:
>>>
>>> On Thursday 16 January 2014 12:14:49 Gary Bilkus wrote:
>>>
>>>
So just to make sure I understand exactly what you need.
>>>
On Jan 17, 2014, at 5:57 AM, Gary Bilkus wrote:
> On 16/01/2014 13:23, Geert Janssens wrote:
>>
>> On Thursday 16 January 2014 12:14:49 Gary Bilkus wrote:
>>
>> >
>>
>> > So just to make sure I understand exactly what you need.
>>
>> >
>>
>> > 1. I should get the gnucash.git repository from
On 16/01/2014 13:23, Geert Janssens wrote:
On Thursday 16 January 2014 12:14:49 Gary Bilkus wrote:
>
> So just to make sure I understand exactly what you need.
>
> 1. I should get the gnucash.git repository from
> git://github.com:gjanssens/gnucash.git
> 2. I should git branch -t mingw ori
On 16/01/2014 15:38, Geert Janssens wrote:
On Thursday 16 January 2014 15:06:55 Gary Bilkus wrote:
> On 16/01/2014 13:26, Geert Janssens wrote:
> > Gary,
> >
> > While looking at your changes I noticed you changed two lines in the
> > vbs script.
> >
> > One is that you added my repositor
(Oops, this was meant to go to the list not Gary directly)
On Thursday 16 January 2014 12:06:15 Gary Bilkus wrote:
> On 16/01/2014 11:53, Geert Janssens wrote:
> > On Thursday 26 December 2013 17:41:14 Geert Janssens wrote:
> > > On Wednesday 25 December 2013 18:46:32 Gary Bilkus wrote:
> > > > On
On Thursday 16 January 2014 07:49:53 John Ralls wrote:
> On Jan 16, 2014, at 5:23 AM, Geert Janssens wrote:
> > 3. Apply your patches and ignore those that are already there is
> > also correct. Then before committing anything it's worth
> > considering which changes logically belong together and
On Jan 16, 2014, at 5:23 AM, Geert Janssens wrote:
> 3. Apply your patches and ignore those that are already there is also
> correct. Then before
> committing anything it's worth considering which changes logically belong
> together and check
> these changes in in separate commits. 'git add -
On Thursday 16 January 2014 15:06:55 Gary Bilkus wrote:
> On 16/01/2014 13:26, Geert Janssens wrote:
> > Gary,
> >
> > While looking at your changes I noticed you changed two lines in the
> > vbs script.
> >
> > One is that you added my repository/branch in a comment. That's ok
> > and makes it e
On 16/01/2014 13:26, Geert Janssens wrote:
Gary,
While looking at your changes I noticed you changed two lines in the
vbs script.
One is that you added my repository/branch in a comment. That's ok and
makes it easier for others to start.
The second is to install msys-patch. Is there a rea
Gary,
While looking at your changes I noticed you changed two lines in
the vbs script.
One is that you added my repository/branch in a comment.
That's ok and makes it easier for others to start.
The second is to install msys-patch. Is there a reason you do this
in the vbs script and not in in
On Thursday 16 January 2014 12:14:49 Gary Bilkus wrote:
>
> So just to make sure I understand exactly what you need.
>
> 1. I should get the gnucash.git repository from
> git://github.com:gjanssens/gnucash.git
> 2. I should git branch -t mingw origin/mingw-rebasing and check out
> that branch
> 3
On 16/01/2014 11:43, Geert Janssens wrote:
On Thursday 16 January 2014 11:10:30 Geert Janssens wrote:
Gary,
Thanks for all your updates. Today I found some time to check which of
your fixes I should still add to my windows branch, but got lost in
your patch. It looks like you are generating a p
On Thursday 26 December 2013 17:41:14 Geert Janssens wrote:
> On Wednesday 25 December 2013 18:46:32 Gary Bilkus wrote:
> > On 24/12/2013 18:25, Gary Bilkus wrote:
> > > - There seems to be a version issue with GWENHYFAR_VERSION
> > > It builds OK but every time I restart it rebuilds. For some reas
On Thursday 16 January 2014 11:10:30 Geert Janssens wrote:
>
> Gary,
>
> Thanks for all your updates. Today I found some time to check which of
> your fixes I should still add to my windows branch, but got lost in
> your patch. It looks like you are generating a patch to be applied to
> the curre
On Friday 10 January 2014 17:41:15 Gary Bilkus wrote:
> On 10/01/2014 15:03, John Ralls wrote:
> > On Jan 9, 2014, at 11:13 PM, Gary Bilkus wrote:
> >> Well, interestingly enough, the problem is not directly with the
> >> compiler optimizer. It's with the configure test for strncasecmp.
> >> This
On 10/01/2014 15:03, John Ralls wrote:
On Jan 9, 2014, at 11:13 PM, Gary Bilkus wrote:
Well, interestingly enough, the problem is not directly with the compiler
optimizer. It's with the configure test for strncasecmp. This test fails on
mingw in its current incarnation because guile uses a s
On Jan 9, 2014, at 11:13 PM, Gary Bilkus wrote:
> Well, interestingly enough, the problem is not directly with the compiler
> optimizer. It's with the configure test for strncasecmp. This test fails on
> mingw in its current incarnation because guile uses a standard test for the
> function, b
Well, interestingly enough, the problem is not directly with the
compiler optimizer. It's with the configure test for strncasecmp. This
test fails on mingw in its current incarnation because guile uses a
standard test for the function, but on mingw strncasecmp is actually a
cpp definition. As a
Hmm,
The problem appears to be with the compiler optimiser doing something too
aggressive, If I manually recompile guile with -O0 instead of -O2 the problem
seems to go away. This could be caused by one of the new optimisations in the
more recent versions of gcc in which case it could start to
I have written up the procedure which as of today is working to build
gnucash 2.6 from scratch on windows and updated
http://wiki.gnucash.org/wiki/Windows/Development
It would be really nice if the patch file I have created along with my
modified version of geert's vbs file could find their wa
Well done Garry. I am very interested in attempting to build a windows
version too. Can you post on the forum when you have updated the wiki?
Thank you for persisting.
Kim
--
View this message in context:
http://gnucash.1415818.n4.nabble.com/Building-on-Windows-from-scratch-tp4666302p466696
On 07/01/2014 18:16, Derek Atkins wrote:
Gary Bilkus writes:
UPDATE..The problem with the modules appears to be a slight
red-herring to do with having 2.6 around.If I build what seems to be
2.5.something based on the git repository from geert, with all the
changes I've mentioned, I can now
Gary Bilkus writes:
> UPDATE..The problem with the modules appears to be a slight
> red-herring to do with having 2.6 around.If I build what seems to be
> 2.5.something based on the git repository from geert, with all the
> changes I've mentioned, I can now get gnucash to compile and run ( at
On 07/01/2014 13:52, Gary Bilkus wrote:
On 28/12/2013 08:16, Gary Bilkus wrote:
Thanks Geert,
I've got a bit furtherthe program now starts and then dies after
showing a splash screen.
I found a gnucash-launcher.cmd script which didn't quite work,
because it was missing references to libxsl
On 28/12/2013 08:16, Gary Bilkus wrote:
Thanks Geert,
I've got a bit furtherthe program now starts and then dies after
showing a splash screen.
I found a gnucash-launcher.cmd script which didn't quite work, because
it was missing references to libxslt enchant and libsoup
If I add those ( bi
Nice you got it to compile !
With my local modifications I got stuck in engine/test with this error:
/bin/sh ../../../libtool --tag=CC --mode=link gcc -I.
-I/c/soft/gnucash.git/src/engine/test -I../../.. -
I/c/soft/gnucash.git/src/engine/ -DTESTPROG=test_engine -mms-bitfields -
Ic:/soft/gnome/
On Friday 27 December 2013 08:30:34 Gary Bilkus wrote:
> > > A bit further now.
> > >
> > > If I change the REL_REPOS_DIR to $GLOBAL_DIR\\gnucash.git
> >
>
> Hi Geert,
> I was indeed running install.sh - the version I found in
> packaging/win32 The reference to REL_REPOS_DIR is actuall in
>
Hi,
Gary Bilkus writes:
> Anyway, I've made some more progress. The -no-undefined problem is
> caused because more recent versions of gcc apparently don't understand
> that flag, and don't ignore it but just fail. So although you need to
> pass it to libtool, you mustn't pass it direct to gcc.an
> A bit further now.
> If I change the REL_REPOS_DIR to $GLOBAL_DIR\\gnucash.git
This doesn't make sense to me. REL_REPOS_DIR is not used in the
install script, but only in the nightly build scripts.
Which script are you running exactly to build gnucash ?
It should be install.sh
> the
On Wednesday 25 December 2013 18:46:32 Gary Bilkus wrote:
> On 24/12/2013 18:25, Gary Bilkus wrote:
> >> > So it carried on until
> >> >
> >> > extracting libdbi-0.8.4.tar.gz ... done
> >> >
> >> >
> >> >
> >> > Hunk #2 FAILED at 154
> >> >
> >> > 1 out of 4 hunks FAILED
> >> >
> >> >
On 24/12/2013 18:25, Gary Bilkus wrote:
> So it carried on until
> extracting libdbi-0.8.4.tar.gz ... done
>
> Hunk #2 FAILED at 154
> 1 out of 4 hunks FAILED
>
> Will look further later.
Odd I could build. But then again I did so many rebuilds, perhaps I
worked with a differen
> So it carried on until
> extracting libdbi-0.8.4.tar.gz ... done
>
> Hunk #2 FAILED at 154
> 1 out of 4 hunks FAILED
>
> Will look further later.
Odd I could build. But then again I did so many rebuilds, perhaps I
worked with a different patch than what I eventually committed.
On Tuesday 24 December 2013 09:52:16 Gary Bilkus wrote:
>
> Thanks Geert.
> I've tried as you suggested. There's one typo above I think
> REPOS_URL = "git://github.com:gjanssens/gnucash.git"
> didn't work for me, but git://github.com/gjanssens/gnucash.git
> did.
>
Yes, I started from my own remot
I'm sorry I didn't mention this more clearly. The documentation is not
updated yet. So the information in the README file is still for the
old build process.
This is how I think you should proceed (I'm assuming you stick with
the default path names):
- clear every trace of the previous gnu
On Monday 23 December 2013 16:04:56 Gary Bilkus wrote:
> Hi Geert,
> I've downloaded your repository and started trying to follow the
> instructions in the README in /packaging/win32
> But I'm not getting very far
> 1. The location of MSYS needs to change from:
> https://sourceforge.net/proje
On 21/12/2013 14:44, Geert Janssens wrote:
On Friday 20 December 2013 18:34:50 Gary Bilkus wrote:
> Hi Geert,
>
> If you're already well into solving the problem, I'd be very happy to
> try and help with that effort. I will take a look at your repository
> at some point during the next f
On Friday 20 December 2013 18:34:50 Gary Bilkus wrote:
> Hi Geert,
>
> If you're already well into solving the problem, I'd be very happy to
> try and help with that effort. I will take a look at your repository
> at some point during the next few days.
> Would you expect this to work under 64 b
Gary Bilkus writes:
> I will probably set up a dedicated linux box to do any actual
> development, but the end result has to work for other people who only
> have Windows knowledge and are not willing to mess around with virtual
> systems etc.
>
>
> Since I have no right to expect that any chan
Hi Geert,
If you're already well into solving the problem, I'd be very happy to try and
help with that effort. I will take a look at your repository at some point
during the next few days.
Would you expect this to work under 64 bit versions of Windows, or are the
other comments about this stil
On Friday 20 December 2013 14:25:26 Gary Bilkus wrote:
> I will probably set up a dedicated linux box to do any actual
> development, but the end result has to work for other people who only
> have Windows knowledge and are not willing to mess around with
> virtual systems etc.
>
> Since I have
I will probably set up a dedicated linux box to do any actual development, but
the end result has to work for other people who only have Windows knowledge and
are not willing to mess around with virtual systems etc.
Since I have no right to expect that any changes I make will end up in the
of
On 20 December 2013 12:59, Gary Bilkus wrote:
> Thanks for the info.
>
> I will set up a windows 32 bit virtual machine and try to follow the
> instructions one by one. Should I report each problem to this list or
> privately to somewhere else. I'm happy to put in the work to ensure that the
>
Thanks for the info.
I will set up a windows 32 bit virtual machine and try to follow the
instructions one by one. Should I report each problem to this list or privately
to somewhere else. I'm happy to put in the work to ensure that the instructions
are clear.
BTW, the reason I want to be able
Dear Gary,
I've used those instructions several times, and quite successfully each time
(although it takes hours).
Am Donnerstag, 19. Dezember 2013, 09:36:28 schrieb Gary Bilkus:
> Has anyone actually succeeded in following the instructions on the wiki page
> http://wiki.gnucash.org/wiki/Window
Hi,
Gary Bilkus writes:
> Has anyone actually succeeded in following the instructions on the
> wiki page http://wiki.gnucash.org/wiki/Windows/Development from
> scratch and ending up with a working gnucash. Or is there some other
> hidden set of instructions.
>
>
> I have tried to build gn
96 matches
Mail list logo
