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

[Simon Josefsson]

Massimo Gaspari <massimo.gaspari at alice.it> writes:

> Simon Josefsson wrote:
>
>> Massimo Gaspari <massimo.gaspari at alice.it> writes:
>
>> Yes, that is one solution, however doing it systematically for each and
>> every symbol defined by gnulib is a lot of work.
>>
>> Maybe you could add '#define vasprintf gnutls_vasprintf' in your
>> config.h when building GnuTLS?  I'm not sure it will work, but something
>> like that will be necessary to fully solve this problem.
>>   
> Up to now only the vasprintf seems to have problems. So It's not
> difficult to change the code.

Right.

> Moreover if you use the following link
>
> http://hpux.cs.utah.edu/hppd/cgi-bin/wwwtar?/hpux/Gnu/gnutls-2.3.4/gnutls-2.3.4-src-11.11.tar.gz+gnutls-2.3.4/HPUX.Install+text
>
> you find some suggestion to get GnuTls compiled in HPUX for
> 2.3.4. There's the following comment
>
> * doc/examples/Makefile.in:
>  - Use ../../gl/.libs/libgnu.la at the end of the libtool link line
>    to link examples, rather than ../../gl/libgnu.la in the middle of the
>    line. This avoids a missing rpl_strerror symbol when linking on the
>    Itanium platform.
>
> So I'm not alone :-)

Thanks for the pointer!  There is plenty of stuff we should fix there.
I'll go through it.  I don't have access to a HPUX platform, but some
may be possible to fix anyway.

>> To build the manual, you need a newer texinfo.  However, building it
>> shouldn't be required unless you modified any source files that is used
>> by the manual.  Possibly you have done that...  I think this should go
>> away when all your other build problems are solved in the official
>> distribution.
>>   
> I'll update the texinfo package. In the meantime I can skip the doc
> building using an empty Makefile
>
> all:
> check:
>
> (quick and dirty, but better than an error)

Yup.

> 3) GnuTLS
>
> Edit the sources changing any vasprintf to gnutls_vasprintf
> (stdio.in.h, vasprintf.c, asprintf.c and gnutls_str.c)
> Edit the config.h.in to have #define HAVE_ALLOCA 0 and #define
> HAVE_ALLOCA_H 0
>
> ./configure --disable-shared --disable-rpath --disable-cxx --disable-guile
>
> Edit config.h to have #define HAVE_ALLOCA 0 (configure sets HAVE_ALLOCA 1)
> Edit Makefile in doc to do nothing
> Edit Makefile in doc/example adding ../../gl/libgnu.la to LIBS

Thanks for summarizing this.  I'll see if I can add the gnulib alloca
module now, it should fix the alloca problem.

> pkix_asn1_tab.c:7: warning: 'pkix_asn1_tab' initialized and declared
> extern'
...
> gnutls_asn1_tab.c:7: warning: 'gnutls_asn1_tab' initialized and
> declared 'extern'
>
> I think the compiler is right. The two variable are used in
>
> pkix_asn1_tab.c
> gnutls_global.c
>
> in both files you use the extern qualifier, but in pkix_asn1_tab.c you
> also assign a "value". Wouldn't it be better to remove the extern
> qualifier in
> pkix_asn1_tab.c? Ok is a very minor issue but avoid two warnings.

Right.  Those files are generated, and I had fixed this problem in
libtasn1 but not re-generated the files in GnuTLS.  I've installed
freshly generated files now.

> So is this the end of the story? Unfortunately no!!

But very close. :)

> -               Not Before: Fri Jan 26 10:00:04 UTC 2007
> -               Not After: Sat Jan 27 10:00:06 UTC 2007
> +               Not Before: Fri Jan  10:00:04 UTC 2007
> +               Not After: Sat Jan  10:00:06 UTC 2007

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)

Could you try replacing all occurrences of '%e' to '%d' in
lib/x509/output.c, re-build and re-run the self tests?

> Googling the internet I  got the opinion that this may be related to
> isprint(), I'm not sure anyway. Is the following recommandation (from
> HPUX suggestions) relevat to the failure?
>
> * lib/x509/output.c:
>  - The isprint() routine on Itanium platforms seemed to like printing
>    8-bit chars (possibly to do with the sign of the char?), so changed it
>    to simply print any char between ' ' and '~'. Without this change,
>    Itanium's "gmake check" fails one of the checks.

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.

/Simon