Am 30.01.2020 um 22:05 schrieb Brian Inglis:
On 2020-01-29 06: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.
For these to be considered missing or deficient such that they should be
provided or replaced gnulib must consider Cygwin lacking support for ANSI C
fflush https://www.gnu.org/software/gnulib/MODULES.html#ansic_enh_stdio
and POSIX 2008 fseek and fseeko supporting pipes and 4GB in 32 bit mode
https://www.gnu.org/software/gnulib/MODULES.html#posix_sup
perhaps as a result of incorrect conclusions about Cygwin in autoreconf?
I was able to rebuild 5.1.0 successfully on a x86_64 cygwin1.dll
built from git source.
Nor flush or fseek gnulib modules were built.
During weekend I will replicate with i686.
Regards
Marco
--
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
