W32 testsuite results

[Nikos Mavrogiannopoulos]

On 04/04/2011 06:01 PM, LRN wrote:
> On 04.04.2011 18:15, Nikos Mavrogiannopoulos wrote:
>> On 04/04/2011 03:04 AM, LRN wrote:
>>> Does anyone have testsuite (make -k check) results for gnutls-2.12.1 on
>>> W32 (i would prefer native W32, but the ones from Wine are better than
>>> nothing at all)? Built against libgcrypt.
>>> I'm building gnutls myself (with some minor patches) and i'm not sure
>>> whether my mixed testsuite results are expected (known bugs or unported
>>> features) or not (i broke something).
>> Not me. Which tests failed? Do gnutls-cli and gnutls-serv operate?

> FAIL: test-binary-io.sh
> FAIL: mini.exe
> FAIL: hostname-check.exe
> FAIL: chainverify.exe
> FAIL: mini-eagain.exe
> FAIL: mini-x509.exe
> FAIL: mini-x509-rehandshake.exe
> FAIL: pgps2kgnu.exe

Did these tests succeed in previous gnutls versions at win32?
Unfortunately I cannot debug them, but if you run individual tests
with the -v option, they will provide more information about the
actual point of failure.

> I'm blaming test-binary-io.sh on libtool (the test itself, the one in
> .libs subdirectory, exits with 0 and writes the right 6-byte string into
> stdout, but when it is run by a libtool wrapper, _spawn() returns 3).

I have no idea about this test. It is a gnulib test. It should have
been introduced on the previous gnulib update.

> Hangs up at "Checking DSA-1024 with TLS 1.0" (or, rather, enters
> infinite loop; consumes very little resources though, so it must either
> use a timer or some kind of wait function), have to kill the server to
> kick it going again (or kill the client. Twice. And then kill the
> server, also twice, because it just keeps waiting for a client to connect).
> 
> Also, obviously, i've had to skip rng-fork (because it uses fork()) and
> openpgp-auth (because it uses socketpair(), and with unix domain sockets
> at that!) tests. Other tests had to be patched to NOT to include
> #include <sys/wait.h> and some other headers not provided by MinGW.

Could you send me those changes?

> I've also submitted a bug report about mini.exe (see the bug tracker),
> because its cause seemed obvious to me (writes/reads to/from
> fd==0xffffffff).

This shouldn't be a problem. The mini-* programs use fd==0xfffffff
because they emulate the communication and don't really use an fd.

regards,
Nikos