bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: libidn 1.23


From: Simon Josefsson
Subject: Re: libidn 1.23
Date: Wed, 30 Nov 2011 12:11:52 +0100
User-agent: Gnus/5.110018 (No Gnus v0.18) Emacs/24.0.91 (gnu/linux)

Bruno Haible <address@hidden> 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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]