Am 30.01.2020 um 22:05 schrieb Brian Inglis:
On 2020-01-29 06:46, Takashi Yano wrote:
Hi Marco,
On Wed, 29 Jan 2020 13:19:11 +0100
Marco Atzeri wrote:
As Octave uses gnulib, it is possible that the changes in MS are causing
a different subset of gnulib to be used than before, may be exposing
a
On 2020-01-29 06:46, Takashi Yano wrote:
> Hi Marco,
>
> On Wed, 29 Jan 2020 13:19:11 +0100
> Marco Atzeri wrote:
>> As Octave uses gnulib, it is possible that the changes in MS are causing
>> a different subset of gnulib to be used than before, may be exposing
>> a latent bug or race.
>>
>> Unfor
On Jan 30 01:08, Takashi Yano wrote:
> On Wed, 29 Jan 2020 16:34:28 +0100
> Corinna Vinschen wrote:
> > On Jan 29 16:32, Corinna Vinschen wrote:
> > > On Jan 29 22:46, Takashi Yano wrote:
> > > > --- m4/fseeko.m4.orig 2020-01-29 21:39:37.280507900 +0900
> > > > +++ m4/fseeko.m42020-01-29
Am 29.01.2020 um 16:39 schrieb Hans-Bernhard Bröker:
[Ooops, sent this to Takashi instead of the list, originally.]
Am 29.01.2020 um 14:46 schrieb Takashi Yano:
On Wed, 29 Jan 2020 13:19:11 +0100
Marco Atzeri wrote:
As Octave uses gnulib, it is possible that the changes in MS are causing
a d
On Wed, 29 Jan 2020 16:34:28 +0100
Corinna Vinschen wrote:
> On Jan 29 16:32, Corinna Vinschen wrote:
> > On Jan 29 22:46, Takashi Yano wrote:
> > > --- m4/fseeko.m4.orig 2020-01-29 21:39:37.280507900 +0900
> > > +++ m4/fseeko.m42020-01-29 21:36:29.263747100 +0900
> > > @@ -30,16 +30,19 @
[Ooops, sent this to Takashi instead of the list, originally.]
Am 29.01.2020 um 14:46 schrieb Takashi Yano:
On Wed, 29 Jan 2020 13:19:11 +0100
Marco Atzeri wrote:
As Octave uses gnulib, it is possible that the changes in MS are causing
a different subset of gnulib to be used than before, may
On Jan 29 16:32, Corinna Vinschen wrote:
> On Jan 29 22:46, Takashi Yano wrote:
> > --- m4/fseeko.m4.orig 2020-01-29 21:39:37.280507900 +0900
> > +++ m4/fseeko.m42020-01-29 21:36:29.263747100 +0900
> > @@ -30,16 +30,19 @@
> > HAVE_FSEEKO=0
> >else
> > if test $WINDOWS_64_BIT
On Jan 29 22:46, Takashi Yano wrote:
> Hi Marco,
>
> On Wed, 29 Jan 2020 13:19:11 +0100
> Marco Atzeri wrote:
> > As Octave uses gnulib, it is possible that the changes in MS are causing
> > a different subset of gnulib to be used than before, may be exposing
> > a latent bug or race.
> >
> > Unf
On Wed, 29 Jan 2020 22:46:53 +0900
Takashi Yano wrote:
> On Wed, 29 Jan 2020 13:19:11 +0100
> Marco Atzeri wrote:
> > As Octave uses gnulib, it is possible that the changes in MS are causing
> > a different subset of gnulib to be used than before, may be exposing
> > a latent bug or race.
> >
> >
Hi Marco,
On Wed, 29 Jan 2020 13:19:11 +0100
Marco Atzeri wrote:
> As Octave uses gnulib, it is possible that the changes in MS are causing
> a different subset of gnulib to be used than before, may be exposing
> a latent bug or race.
>
> Unfortunately my old build tree was polluted by mistake, s
Am 29.01.2020 um 10:44 schrieb Corinna Vinschen:
On Jan 28 07:41, Marco Atzeri wrote:
Am 27.01.2020 um 12:33 schrieb Takashi Yano:
On Mon, 27 Jan 2020 07:45:08 +0100
Marco Atzeri wrote:
Can you and Takashi provide me your cygcheck.out so that I can look on
possible difference that could influe
On Jan 28 07:41, Marco Atzeri wrote:
> Am 27.01.2020 um 12:33 schrieb Takashi Yano:
> > On Mon, 27 Jan 2020 07:45:08 +0100
> > Marco Atzeri wrote:
> > > Can you and Takashi provide me your cygcheck.out so that I can look on
> > > possible difference that could influence the build behaviour.
> >
>
Am 29.01.2020 um 01:02 schrieb Hans-Bernhard Bröker:
Am 25.01.2020 um 17:55 schrieb Marco Atzeri:
The problem occurs the same way, here, running Win10 Pro 1909 fully
updated (a.k.a. Version 10.0.18363.592), no extra AntiVirus running
besides Defender.
Be aware that build time is very lon
Am 29.01.2020 um 01:02 schrieb Hans-Bernhard Bröker:
So re-run it in gdb, via libtool (run-octave -g ...). Still crashes,
but I didn't manage to get around the SIGSEGV handler in octave. It
always caught the SEGV before gdb managed to get there.
So my finding, so far, would be that this is
Am 25.01.2020 um 17:55 schrieb Marco Atzeri:
libinterp/corefcn/file-io.cc-tst
...fatal: caught signal Segmentation fault
-- stopping myself...
/bin/sh: line 1: 3771 Segmentation fault (core dumped) /bin/sh
../run-octave --norc --silent --no-history -p
/cyg
Marco Atzeri writes:
> I just found that my W10 Home is 1909 build 18363.592 so probably was
> updated as your around mid Jan
>
> https://docs.microsoft.com/en-us/windows/release-information/
>
> But Corporate versions have different time table and patch
Enterprise is, yes.
> the one I have is Ve
Am 28.01.2020 um 18:25 schrieb ASSI:
Achim Gratz writes:
Same thing here…
Since some of the discussion revolved on Windows versions: that is on
Win10 Pro 1909, fully patched. I no longer have a system with 1809
since the period where you could hold up the update has expired
recently. There i
Achim Gratz writes:
> Same thing here…
Since some of the discussion revolved on Windows versions: that is on
Win10 Pro 1909, fully patched. I no longer have a system with 1809
since the period where you could hold up the update has expired
recently. There is an ISO image for Windows Server 2016
On Tue, 28 Jan 2020 07:41:43 +0100
Marco Atzeri wrote:
> So I am now almost sure that the recent MS updates changed/broke
> something in W10 Home. :-((
I have tried now in Win10 Home 1909, and segmentagion fault
has occured at the same place as you.
Microsoft Windows [Version 10.0.18363.592]
--
Am 27.01.2020 um 12:33 schrieb Takashi Yano:
On Mon, 27 Jan 2020 07:45:08 +0100
Marco Atzeri wrote:
Can you and Takashi provide me your cygcheck.out so that I can look on
possible difference that could influence the build behaviour.
Attached.
Thanks Takashi,
I duplicated your installation
Am 25.01.2020 um 19:15 schrieb Brian Inglis:
On 2020-01-25 09:55, Marco Atzeri wrote:
Now I am seriously thinking about BLODA, but I have not
noted any difference from the two AVs I was using
Antivir and MS Defender, so I am wandering if last
update for W10 Home x64 is the culprit.
Also wha
Am 26.01.2020 um 09:38 schrieb Marco Atzeri:
Am 26.01.2020 um 09:05 schrieb ASSI:
Marco Atzeri writes:
at least I know that is not just my machine.
When I released the package was
libinterp/corefcn/file-io.cc-tst
... PASS 90/90
Based on the test name there may
On Sun, 26 Jan 2020 11:24:50 +0100
Marco Atzeri wrote:
> Am 26.01.2020 um 06:11 schrieb Takashi Yano:
> > On Sun, 26 Jan 2020 11:42:28 +0900
> > Takashi Yano wrote:
> >> In my environment, at least segmentation fault does not occur.
> >> When I built octave, many of non-mandatory libraries were not
Am 26.01.2020 um 06:11 schrieb Takashi Yano:
On Sun, 26 Jan 2020 11:42:28 +0900
Takashi Yano wrote:
In my environment, at least segmentation fault does not occur.
When I built octave, many of non-mandatory libraries were not
installed. This might affect.
Now I added all libraries warned in con
Am 26.01.2020 um 09:05 schrieb ASSI:
Marco Atzeri writes:
at least I know that is not just my machine.
When I released the package was
libinterp/corefcn/file-io.cc-tst
... PASS 90/90
Based on the test name there may be an assumption built into the code
about ho
Marco Atzeri writes:
> at least I know that is not just my machine.
> When I released the package was
>
>
> libinterp/corefcn/file-io.cc-tst
> ... PASS 90/90
Based on the test name there may be an assumption built into the code
about how the filesystem behaves that is
Am 25.01.2020 um 21:36 schrieb Achim Gratz:
Marco Atzeri writes:
Than I passed to build the next version and started to see
unexpected segfault during the package test.
Trying to investigate I rebuilt the 5.1.0 and now I see also
there the same thing:
libinterp/corefcn/file-io.cc-tst
...
On Sun, 26 Jan 2020 11:42:28 +0900
Takashi Yano wrote:
> In my environment, at least segmentation fault does not occur.
> When I built octave, many of non-mandatory libraries were not
> installed. This might affect.
Now I added all libraries warned in config.log, and rebuilt.
Some of tests seems t
On Sat, 25 Jan 2020 17:55:31 +0100
Marco Atzeriwrote:
>libinterp/corefcn/file-io.cc-tst
> ...fatal: caught signal Segmentation fault
> -- stopping myself...
> /bin/sh: line 1: 3771 Segmentation fault (core dumped) /bin/sh
> ../run-octave --norc --silent --no
Marco Atzeri writes:
> Than I passed to build the next version and started to see
> unexpected segfault during the package test.
> Trying to investigate I rebuilt the 5.1.0 and now I see also
> there the same thing:
>
> libinterp/corefcn/file-io.cc-tst
> ...fatal: caug
On 2020-01-25 09:55, Marco Atzeri wrote:
> Hi All,
> I have recently released Octave 5.1.0
>
> https://cygwin.com/ml/cygwin-announce/2020-01/msg00010.html
> https://cygwin.com/ml/cygwin-announce/2020-01/msg00011.html
>
> that I built and packaged around 28 of December without
> any compilation an
Hi All,
I have recently released Octave 5.1.0
https://cygwin.com/ml/cygwin-announce/2020-01/msg00010.html
https://cygwin.com/ml/cygwin-announce/2020-01/msg00011.html
that I built and packaged around 28 of December without
any compilation and test issue.
Than I passed to build the next version a
32 matches
Mail list logo
