headache on build repeatibility: octave vs BLODA ?

[Corinna Vinschen]

On Jan 29 16:32, Corinna Vinschen wrote:
> On Jan 29 22:46, Takashi Yano wrote:
> > --- 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=0
> >    else
> >      if test $WINDOWS_64_BIT_OFF_T = 1; then

This makes me a bit suspicious... it looks like a check only
required for native builds, not for Cygwin.

> > -      REPLACE_FSEEKO=1
> > +      dnl REPLACE_FSEEKO=1
> > +      REPLACE_FSEEKO=0
> >      fi
> >      if test $gl_cv_var_stdin_large_offset = no; then
> > -      REPLACE_FSEEKO=1
> > +      dnl REPLACE_FSEEKO=1
> > +      REPLACE_FSEEKO=0
> >      fi
> >      m4_ifdef([gl_FUNC_FFLUSH_STDIN], [
> >        gl_FUNC_FFLUSH_STDIN
> >        case "$gl_cv_func_fflush_stdin" in
> >          *yes) ;;
> > -        *) REPLACE_FSEEKO=1 ;;
> > +        dnl *) REPLACE_FSEEKO=1 ;;
> > +        *) REPLACE_FSEEKO=0 ;;
> >        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

-- 
Corinna Vinschen
Cygwin Maintainer
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://cygwin.com/pipermail/cygwin/attachments/20200129/fb7b724f/attachment.sig>