On Jan 29 22:46, Takashi Yano wrote:
> Hi Marco,
> 
> 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.
> > 
> > Unfortunately my old build tree was polluted by mistake, so I can
> > not directly compare a good build tree versus a failing one.
> 
> I found suspicious difference between the working build and the
> not-working build.
> 
> The not-working build has fflush.o, fseek.o and fseeko.o in
> build/libgnu/.libs
> directory, while the working build does not.
> 
> Also, cygoctave-7.dll of not-working build exports rpl_fflush,
> rpl_fseek and rpl_fseeko, while that of the working build does
> not.
> 
> 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.
> 
> I do not look into the reason why this difference causes yet.
> 
> I would be happy if this could help.
> 
> --- 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
> -      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