DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:date:from:to:subject:message-id:in-reply-to
	:references:mime-version:content-type:content-transfer-encoding;
	 q=dns; s=default; b=Vr/wDXIkLR6Bd+GbaI+YkZuNuD0j+uv/7ACv1v75X4M
	75zvGSQucGvaGkpnyFQW6lNdArNZ6GwbAasBosD//y189V+4YX/CILUiP5ZXUMta
	q6//gRrCa8TE18HNCr1yrTN8D/f3PpwqKlKO1sx30Mn3SuixhCMQXmVzxyXOpaLs
	=
Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm
Sender: cygwin-owner@cygwin.com
Mail-Followup-To: cygwin@cygwin.com
Date: Thu, 30 Jan 2020 00:11:26 +0900
From: Takashi Yano <takashi.yano@nifty.ne.jp>
To: cygwin@cygwin.com
Subject: Re: headache on build repeatibility: octave vs BLODA ?
Message-Id: <20200130001126.8a287e4a98139db99b992770@nifty.ne.jp>
In-Reply-To: <20200129224653.b3238736661d3c95fc30ee5f@nifty.ne.jp>
References: <2904b4fa-6349-bd3e-c4ff-4b32a0bb3838@gmail.com>	<87y2tvs278.fsf@Rainer.invalid>	<9b370970-fcfe-cca9-321f-973de777642a@gmail.com>	<878sluhcc1.fsf@Otto.invalid>	<08ac898e-e7f9-c8e9-91ba-d4ee33f2e27c@gmail.com>	<0fb5712c-7d57-d5cb-56b7-3a0d2f44d8a2@gmail.com>	<20200127203346.1c8e3657d7283e3aa2c617d8@nifty.ne.jp>	<85ddac25-0b4a-5e01-7885-0d2855c37a45@gmail.com>	<20200129094427.GI3549@calimero.vinschen.de>	<9e66f9f1-109f-7a3c-2c86-abd3ef7fc628@gmail.com>	<20200129224653.b3238736661d3c95fc30ee5f@nifty.ne.jp>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

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.
> > 
> > Unfortunately my old build tree was polluted by mistake, so I can
> > not directly compare a good build tree versus a failing one.
> 
> I found suspicious difference between the working build and the
> not-working build.
> 
> The not-working build has fflush.o, fseek.o and fseeko.o in
> build/libgnu/.libs
> directory, while the working build does not.
> 
> Also, cygoctave-7.dll of not-working build exports rpl_fflush,
> rpl_fseek and rpl_fseeko, while that of the working build does
> not.
> 
> As a test, I used following patch to forcibly remove the code
> setting REPLACE_FSEEKO to 1 in configure script, and rebuilt
> octave. This works without segmentation fault.
> 
> I do not look into the reason why this difference causes yet.

Perhaps, the cause of this behaviour change is:

commit 59362c80e3a02c011fd0ef3d7f07a20098d2a9d5
Author: Bastien Bouclet <bastien.bouclet@gmail.com>
Date:   Sat Nov 9 17:28:04 2019 +0100

    newlib: fix fseek optimization with SEEK_CUR

    The call to fflush was invalidating the read buffer, preventing relative
    seeks to positions that would have been inside the read buffer from
    being optimized. The call to srefill would then re-read mostly the same
    data that was initially in the read buffer.

Recently, I executed make only in winsup/cygwin, so this newlib
change did not affect. Therefore this change was not included in
my local cygwin1.dll binary. As for Win10 Home machine, which
causes the problem, cygwin1.dll is v3.1.2, so this is affected. 

-- 
Takashi Yano <takashi.yano@nifty.ne.jp>

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple