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:reply-to
	:references:mime-version:content-type:in-reply-to; q=dns; s=
	default; b=hMIyTFnudt/hZ/mLEP32Ttx/PkBBgYPrygOuLB/yWLx59fHRI1hmz
	fiw1TAf42O63S+0TkpndA4x6qgl3HvxPDSFHgp3pQpI37HHT+UueUQde2h3kLP+9
	Ju0O9UG/Pth4x+n7BAOaIFpPPLS8dapCK8DAU1KCAuZwGR/TqkxPo4=
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:reply-to
	:references:mime-version:content-type:in-reply-to; s=default;
	bh=cNLu555/pF00smWije1Q9gHklCk=; b=mKvEQyif1FU+IpYUyfs1SXJIuRiz
	vgm6uAG+LsfT5jA0cK3qZjiSoBnCrMpDZkMryHDwMeMI41rwifP1i8KbD2ZdiiIB
	0wQ6VsFwfJuu3j/fex9/PsDyWSlCpb3/9jbisaLGxtEUeuavXi/Njx82PQ07Xvfd
	La7m+langfeGs1Y=
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=-112.0 required=5.0 tests=AWL,BAYES_00,GIT_PATCH_2,GIT_PATCH_3,GOOD_FROM_CORINNA_CYGWIN,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 spammy=OpenBSD, openbsd
X-HELO:	mout.kundenserver.de
Date:	Wed, 29 Jan 2020 16:32:18 +0100
From:	Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To:	cygwin AT cygwin DOT com
Subject:	Re: headache on build repeatibility: octave vs BLODA ?
Message-ID:	<20200129153218.GO3549@calimero.vinschen.de>
Reply-To:	cygwin AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
References:	<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
In-Reply-To:	<20200129224653.b3238736661d3c95fc30ee5f@nifty.ne.jp>

--c8JyeaiReRNoiMDS
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Jan 29 22:46, Takashi Yano wrote:
> Hi Marco,
>=20
> 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.
> >=20
> > Unfortunately my old build tree was polluted by mistake, so I can
> > not directly compare a good build tree versus a failing one.
>=20
> I found suspicious difference between the working build and the
> not-working build.
>=20
> The not-working build has fflush.o, fseek.o and fseeko.o in
> build/libgnu/.libs
> directory, while the working build does not.
>=20
> Also, cygoctave-7.dll of not-working build exports rpl_fflush,
> rpl_fseek and rpl_fseeko, while that of the working build does
> not.
>=20
> 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.
>=20
> I do not look into the reason why this difference causes yet.
>=20
> I would be happy if this could help.
>=20
> --- m4/fseeko.m4.orig   2020-01-29 21:39:37.280507900 +0900
> +++ m4/fseeko.m4        2020-01-29 21:36:29.263747100 +0900
> @@ -30,16 +30,19 @@
>      HAVE_FSEEKO=3D0
>    else
>      if test $WINDOWS_64_BIT_OFF_T =3D 1; then
> -      REPLACE_FSEEKO=3D1
> +      dnl REPLACE_FSEEKO=3D1
> +      REPLACE_FSEEKO=3D0
>      fi
>      if test $gl_cv_var_stdin_large_offset =3D no; then
> -      REPLACE_FSEEKO=3D1
> +      dnl REPLACE_FSEEKO=3D1
> +      REPLACE_FSEEKO=3D0
>      fi
>      m4_ifdef([gl_FUNC_FFLUSH_STDIN], [
>        gl_FUNC_FFLUSH_STDIN
>        case "$gl_cv_func_fflush_stdin" in
>          *yes) ;;
> -        *) REPLACE_FSEEKO=3D1 ;;
> +        dnl *) REPLACE_FSEEKO=3D1 ;;
> +        *) REPLACE_FSEEKO=3D0 ;;
>        esac

Commit 59362c80e3a in newlib you mention in your other mail should be a
minor change and the code looks pretty much the same in FreeBSD, while
OpenBSD and NetBSD are more similar to the old newlib code.  Both
implementations should be ok, in theory.

So, the question is, what exactly is this test testing?  Can it be
extracted from the autoconf stuff and converted to a simple testcase
which proves that the behaviour is now wrong?

If so, I'll revert commit 59362c80e3a.


Corinna

--=20
Corinna Vinschen
Cygwin Maintainer

--c8JyeaiReRNoiMDS
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEoVYPmneWZnwT6kwF9TYGna5ET6AFAl4xpYIACgkQ9TYGna5E
T6Byvw/9E2sVYkfgKnL/cMPsZBUV6qPUARgK0XILbfV3UKhXfgdg2MciFyHsj/2v
rYoCIvzhOfPhUliW74JRIKizoDxbnCnyczXI/jlQaA2n6ljqkFtltrj79e4kFpVE
D3JnR0Xu8hz5eNIyv4tp19s6Wu34SQ5WM0jZzQBL6tkZ65b+BsgLjXfORDDyS1xh
bJmJL17hrf0Nes/cR1RRl+hzZr/CsBkGRL5EK7ZhQruSE0A4b9OC6GaPYHhLuNB/
I1x+dh37kRQMyhBzDaWEbxIO6snnMZtWm2i/W6GSDXJGIMBJtGIBCbPJ5+aoPzPo
I9FM0XKCdhTjntn8v7UJ01kGTMc4DRGzlSu/reIGTMBf9UnACZfs7IcXBlR7d32q
MxQuyU5UvVOp2XkMYbfuzc7Vjv+YH+n2Oa+NX36QEU+Z/y9NHuWKBAQ/fw5rHaaY
eX12UrhEO21LfHT2LLlNlqAn9ZacFUcbL79BS3lyUoMho28NGETW0bY70cuoQaUv
TnOXuLga09kGiKukgzCUPhuVUaYLmuR5VNzed0/WXh/dSiBFegfozIkNPRJyUyCi
XZgsCaWK+BJRRWGO2Vu8D2inb+SWS8CP2S0VMeR2u5bNcCchOxOhPl2ohUFnXTjX
p5cSY+QuMkQ11cvr/aAhTO9ySxutIfE0JlZpf4qkqbQwyu7iM68=
=XcFm
-----END PGP SIGNATURE-----

--c8JyeaiReRNoiMDS--

- Raw text -