W32 testsuite results

[LRN]

On 05.04.2011 11:52, Nikos Mavrogiannopoulos wrote:
> 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?
No idea. This is the first time i'm building and testing it by myself 
(used pre-built binaries from http://josefsson.org/gnutls4win/ until 
recently)
> 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.
Would you want me to make a new entry in bug tracker? One for each 
failing test, or just a single entry with debug logs for all failing 
tests? Or just keep discussing it here?
>
>> 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.
That's what i thought. Anyway, i'm not very concerned about it.
>
>> 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?
Attached (these, and some other patches not related to the testsuite; 
you might want to NOT to push these upstream, in particular sigalrm 
patch is completely untested, and testsuite-makefile patch is only 
necessary because some files are missing (?) from the release tarball).
>
>> 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.
>
Oh. Well, anyway, the log is in bug report. If you need anything else - 
just ask.
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: 02-mingw32-don't-look-for-non-existing-makefile.mingw32.patch
URL: </pipermail/attachments/20110405/e15ca580/attachment.asc>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: 03-mingw32-fix-includes-on-windows.mingw32.patch
URL: </pipermail/attachments/20110405/e15ca580/attachment.txt>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: 01-mingw32-fix-sigalrm-on-windows.mingw32.patch
URL: </pipermail/attachments/20110405/e15ca580/attachment-0001.asc>