[Top][All Lists]
[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