[Help-gnutls] Re: gnutls 2.3.4 doesn't copile using MinGW

[Massimo Gaspari]

Simon Josefsson wrote
> Huh!  The day of month is missing.  This suggest a bug in strftime on
> Windows, the code reads:
>
>       if (gmtime_r (&tim, &t) == NULL)
> 	addf (str, "error: gmtime_r (%d)\n", t);
>       else if (strftime (s, max, "%a %b %e %H:%M:%S UTC %Y", &t) == 0)
> 	addf (str, "error: strftime (%d)\n", t);
>       else
> 	addf (str, _("\t\tNot Before: %s\n"), s);
>
> In other words, the '%e' field doesn't work.  Possibly '%d' is more
> portable, from the man page:
>
>        %d     The day of the month as a decimal number (range 01 to 31).
>
>        %e     Like %d, the day of the month as a decimal number, but a leading
>               zero is replaced by a space. (SU)
>   
I read the MSDN documentation and as far as I understand  %e is not 
supported by the Microsoft C Runtime library, it's not listed in the 
available format specifiers.
So because MinGW uses the Microsoft's runtime-lib I got that issue, also 
Visual C should have it.

Anyway I got the latest version as you suggested, gnutls-2.3.6.tar.bz2. 
I see that you changed the %e specifier using %d.

After unpacking I changed the vasprintf to gnutls_vasprintf and nothing 
else. With just this single modification make terminated successfully. 
So the alloca isssue disappeared.

I observed a thing. When I did make for the very first time I didn't get 
the documentation building issue, but then if I do

make clean
make

I get the doc building issue. Does the "make clean" really delete all 
the modified and/or created files? May be not. Anyway I'm going to try 
to update the texinfo (f a new MinGW package is available).

So now 'make test'. The error is still present but is changed to

==================
All 1 tests passed
==================
make[3]: Leaving directory `/home/emasgas/gnutls-2.3.6/tests/userid'
make[2]: Leaving directory `/home/emasgas/gnutls-2.3.6/tests/userid'
Making check in pathlen
make[2]: Entering directory `/home/emasgas/gnutls-2.3.6/tests/pathlen'
make  pathlen
make[3]: Entering directory `/home/emasgas/gnutls-2.3.6/tests/pathlen'
make[3]: Nothing to be done for `pathlen'.
make[3]: Leaving directory `/home/emasgas/gnutls-2.3.6/tests/pathlen'
make  check-TESTS
make[3]: Entering directory `/home/emasgas/gnutls-2.3.6/tests/pathlen'
NOTE: you should run 'diskperf -y' to enable the disk statistics
NOTE: you should run 'diskperf -y' to enable the disk statistics
NOTE: you should run 'diskperf -y' to enable the disk statistics
NOTE: you should run 'diskperf -y' to enable the disk statistics
NOTE: you should run 'diskperf -y' to enable the disk statistics
NOTE: you should run 'diskperf -y' to enable the disk statistics
NOTE: you should run 'diskperf -y' to enable the disk statistics
NOTE: you should run 'diskperf -y' to enable the disk statistics
25c25
<                       ASCII: 
0;09..`.H...E....0*0(..+.........https://www.verisign.com/rpa
---
 >                       ASCII: 
0;09..`.H..øE....0*0(..+.........https://www.verisign.com/rpa
FAIL: pathlen
===================================
1 of 1 tests failed
Please report to bug-gnutls at gnu.org
===================================
make[3]: *** [check-TESTS] Error 1
make[3]: Leaving directory `/home/emasgas/gnutls-2.3.6/tests/pathlen'
make[2]: *** [check-am] Error 2
make[2]: Leaving directory `/home/emasgas/gnutls-2.3.6/tests/pathlen'
make[1]: *** [check-recursive] Error 1
make[1]: Leaving directory `/home/emasgas/gnutls-2.3.6/tests'
make: *** [check-recursive] Error 1

Is still pathlen. There is a ø difference!!! Tomorrow I'll try to 
understand what that test is doing.

Because the issue is in the runtime lib I think that without a patch 
neither MinGW nor Visual C can pass the test. But I think you couldn't 
care less of Visual C :-),  is it?
> Nope, this is not related.  The problem here is that if the platform has
> this bug, gnutls will print non-ascii characters when printing X.509
> subject/issuer names.  We should fix that too, but it is more difficult
> to do if nobody can help debug any proposed fix.
>   
I can help you  for the  MinGW environment. Or, at least, I would. I 
don't know if I'm really helping you or not. :-)

So the last issue for compilation is the vasprintf. Are you going to 
change something? May be the least is to add a comment to the 
installation instruction.

Massimo.