Bruno Haible <br...@clisp.org> writes: > Simon Josefsson wrote: >> This also came up for Libidn, it is using the latest gnulib. >> >> > * mingw with gcc >> > >> > Fails already in the gnulib tests: >> > >> > FAIL: test-binary-io.sh >> >> I have not seen this test fail before. > > I'm seeing this test failure only in the libidn and gsasl builds, not > in the gnulib testdir. > > Debugging it, it turns out that the failure comes from the libtool wrapper: > > $ ./test-binary-io.exe > t-bin-out1.tmp ; echo $? > 3 > > $ .libs/test-binary-io.exe > t-bin-out1.tmp ; echo $? > 0 > > The exit code 3 means that the child process (.libs/test-binary-io.exe) caught > a signal (cf. lib/sys_wait.in.h). > > The cause is that when the libtool wrapper is present, the wrapper process > keeps stdin, stdout, stderr open, therefore the fclose(stdout) statement > in the child process does not have the effect of flushing the file's data > to disk, because the OS is waiting for the second file handle in the parent > process to be closed as well. > > The details of how the libtool wrapper program works can be seen in > .libs/lt-test-binary-io.c: > > /* execv doesn't actually work on mingw as expected on unix */ > newargz = prepare_spawn (newargz); > rval = _spawnv (_P_WAIT, lt_argv_zero, (const char * const *) newargz); > > I'm applying this fix.
Thank you! I have re-added the test-binary-io module to libidn for future releases. /Simon
