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=
Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm
Sender: cygwin-owner@cygwin.com
Mail-Followup-To: cygwin@cygwin.com
Date: Wed, 29 Jan 2020 16:32:18 +0100
From: Corinna Vinschen <corinna-cygwin@cygwin.com>
To: cygwin@cygwin.com
Subject: Re: headache on build repeatibility: octave vs BLODA ?
Message-ID: <20200129153218.GO3549@calimero.vinschen.de>
Reply-To: cygwin@cygwin.com
Mail-Followup-To: cygwin@cygwin.com
References: <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: multipart/signed; micalg=pgp-sha256;	protocol="application/pgp-signature"; boundary="c8JyeaiReRNoiMDS"
Content-Disposition: inline
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--