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
])
fi
--- m4/fflush.m4.orig 2020-01-29 21:40:07.546238000 +0900
+++ m4/fflush.m4 2020-01-29 21:38:02.079793700 +0900
@@ -16,7 +16,8 @@
gl_FUNC_FFLUSH_STDIN
case "$gl_cv_func_fflush_stdin" in
*yes) ;;
- *) REPLACE_FFLUSH=1 ;;
+ dnl *) REPLACE_FFLUSH=1 ;;
+ *) REPLACE_FFLUSH=0 ;;
esac
])
--
Takashi Yano <takashi.y...@nifty.ne.jp>
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
