headache on build repeatibility: octave vs BLODA ?
Corinna Vinschen
corinna-cygwin@cygwin.com
Wed Jan 29 15:34:00 GMT 2020
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>
More information about the Cygwin
mailing list