delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin/2020/01/29/10:12:32

X-Recipient: archive-cygwin AT delorie DOT com
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
=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; 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;
s=default; bh=14GQPk2JymiI9QZBPkZ3tUpGAPw=; b=KpqeawbdVNej7+VD0
lCszveSg1bDwLHA6nVMI/rdC8Y/A4gHzfFbKu1U7p+gk1xLHS7TIlArb//ajL3YT
f1yg3/3hf1+MHouoAmb/Wi18S1U5xFSUJ0M6C3ZTsoIiUK70i4TOqew94bXOlXGu
GfsvAYFVVtiEkri3caytjxJLaU=
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id: <cygwin.cygwin.com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
Authentication-Results: sourceware.org; auth=none
X-Spam-SWARE-Status: No, score=-5.1 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 spammy=fflush, HX-Languages-Length:1882
X-HELO: conssluserg-05.nifty.com
DKIM-Filter: OpenDKIM Filter v2.10.3 conssluserg-05.nifty.com 00TFBLoC018681
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nifty.ne.jp; s=dec2015msa; t=1580310681; bh=96EctvlDUDJZWMJIcFFvrNQiOPfmDLIKyH9X+W0IKO0=; h=Date:From:To:Subject:In-Reply-To:References:From; b=GWDebXUZGOcBhuFSy+aSpjDcf8gBj5f5i/OU/DMXwiDEVSP3UqTJFluEEtqBKLwZO NPR+yACXSiaOQVkhYq2kU7S73GohNQsakpb+oXbWhPRto6wk/IPihd2pt50pn1bcJh Mc6VMWI1rAEmeqE4eAaXYtzRa5HU42a9rpe2X0NKfKQYaVwjRqvZMAr5yli5up9uZg sKOge3H8rjqxtaLbDQtkKnBb/ygDwyXGNKCIzBig6vsFWPH+6g+wW4671JHsxZrIAB mnrTGBeYfi9wbxPhwNEzLjVwcyTtB4hzI0SGS17xdni6kmfAAqgE5Yg/b5nSaogFLq kchloQhmBQiZA==
Date: Thu, 30 Jan 2020 00:11:26 +0900
From: Takashi Yano <takashi DOT yano AT nifty DOT ne DOT jp>
To: cygwin AT cygwin DOT 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 AT gmail DOT com> <87y2tvs278 DOT fsf AT Rainer DOT invalid> <9b370970-fcfe-cca9-321f-973de777642a AT gmail DOT com> <878sluhcc1 DOT fsf AT Otto DOT invalid> <08ac898e-e7f9-c8e9-91ba-d4ee33f2e27c AT gmail DOT com> <0fb5712c-7d57-d5cb-56b7-3a0d2f44d8a2 AT gmail DOT com> <20200127203346 DOT 1c8e3657d7283e3aa2c617d8 AT nifty DOT ne DOT jp> <85ddac25-0b4a-5e01-7885-0d2855c37a45 AT gmail DOT com> <20200129094427 DOT GI3549 AT calimero DOT vinschen DOT de> <9e66f9f1-109f-7a3c-2c86-abd3ef7fc628 AT gmail DOT com> <20200129224653 DOT b3238736661d3c95fc30ee5f AT nifty DOT ne DOT jp>
Mime-Version: 1.0
X-IsSubscribed: yes

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 DOT bouclet AT gmail DOT 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 DOT yano AT nifty DOT ne DOT 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

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019