From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 102851 invoked by alias); 29 Jan 2020 15:32:24 -0000 Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Received: (qmail 102836 invoked by uid 89); 29 Jan 2020 15:32:23 -0000 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 Received: from mout.kundenserver.de (HELO mout.kundenserver.de) (212.227.17.13) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 29 Jan 2020 15:32:22 +0000 Received: from calimero.vinschen.de ([24.134.7.25]) by mrelayeu.kundenserver.de (mreue106 [212.227.15.183]) with ESMTPSA (Nemesis) id 1MZk5x-1j2eNY2eKF-00Wq0l for ; Wed, 29 Jan 2020 16:32:19 +0100 Received: by calimero.vinschen.de (Postfix, from userid 500) id C8F91A80BDD; Wed, 29 Jan 2020 16:32:18 +0100 (CET) Date: Wed, 29 Jan 2020 15:32:00 -0000 From: Corinna Vinschen 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> X-SW-Source: 2020-01/txt/msg00294.txt.bz2 --c8JyeaiReRNoiMDS Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-length: 2369 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" Content-length: 833 -----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--