Building GnuTLS 3.0.9 on MS-Windows

[Nikos Mavrogiannopoulos]

On 01/07/2012 02:41 PM, Eli Zaretskii wrote:

> About a week ago, I've built GnuTLS 3.0.9 on MS-Windows using MinGW 
> GCC-based development environment and MSYS shell and tools (the
> latter are needed for having Bash and related programs necessary to
> run Unix shell scripts such as `configure' and `libtool'). This
> message is a report on the problems I found.  Some of them might

> be Windows-specific, but I think that at least some are not.


Hi Eli, thanks for the information.

> Problem #1: Compilation fails in lib/accelerated/x86:
> 
> make[4]: Entering directory
> `/d/usr/eli/utils/gnutls-3.0.9/lib/accelerated/x86' /bin/sh
> ../../../libtool  --tag=CC --tag=CC  --mode=compile gcc -std=gnu99
> -DHAVE_CONFIG_H -I. -I../../..  -I./../../../gl -I./../../../gl
> -I./../../includes -I./../../includes -I./../../ -I./../
> -I./../../minitasn1 -I/d/usr/include     -DASM_X86_32 -DASM_X86 -g
> -O2 -MT sha-padlock.lo -MD -MP -MF .deps/sha-padlock.Tpo -c -o
> sha-padlock.lo sha-padlock.c libtool: compile:  gcc -std=gnu99
> -DHAVE_CONFIG_H -I. -I../../.. -I./../../../gl -I./../../../gl
> -I./../../includes -I./../../includes -I./../../ -I./../
> -I./../../minitasn1 -I/d/usr/include -DASM_X86_32 -DASM_X86 -g -O2
> -MT sha-padlock.lo -MD -MP -MF .deps/sha-padlock.Tpo -c sha-padlock.c
> -DDLL_EXPORT -DPIC -o .libs/sha-padlock.o sha-padlock.c:24:24:
> gnutls_int.h: No such file or directory sha-padlock.c:25:29:
> gnutls_hash_int.h: No such file or directory sha-padlock.c:26:27:
> gnutls_errors.h: No such file or directory In file included from
> ./aes-padlock.h:5, from sha-padlock.c:30: ./aes-x86.h:24: error:
> syntax error before "size_t" ./aes-x86.h:28: error: syntax error
> before "size_t" followed by many more error messages.
> This happens because no -I flag points to the ../../../lib
> directory, where the headers live.


I see there is however a "-I./../../", isn't ../../ the same as ../../../lib in your build?

> My analysis of this was that it is impossible to build both static 
> and dynamic libraries on Windows in the same build.  If that is true,
> then the `configure' script should be modified to not try that by
> default; the default should probably build only the dynamic 
> libraries. In any case, configuring with ./configure
> --build=i686-pc-mingw32 --prefix=/d/usr --disable-shared succeeds and
> produces a static library libgnutls.a (but not before bumping into a
> couple of more problems, described below).


According to libtool documentation this should have been done by libtool.

"By default, this macro turns on shared libraries if they are
 available, and also enables static libraries if they don't
 conflict with the shared libraries."

Thus it looks like a libtool bug. However I'd suggest you use the alternative
option of building a shared libgnutls instead so you can replace it in
case of important security fixes (e.g. now the one with DTLS).

> Problem #3: The linker fails in src/: CC     udp-serv.o udp-serv.c:
> In function `udp_server': udp-serv.c:107: warning: implicit
> declaration of function `usleep' CC     common.o CC     p11common.o 
> CCLD   gnutls-serv.exe udp-serv.o(.text+0x417): In function
> `udp_server': d:/usr/eli/utils/gnutls-3.0.9/src/udp-serv.c:107:
> undefined reference to `usleep'


I'll add the gnulib usleep module for that. 

> Problem #4: Linker fails in src/:
> 
> CC     serv.o serv.c: In function `human_addr': serv.c:620: warning:
> implicit declaration of function `getnameinfo' serv.c: In function
> `listen_socket': serv.c:697: warning: implicit declaration of
> function `getaddrinfo' serv.c:776: warning: implicit declaration of
> function `freeaddrinfo' CC     common.o CC     p11common.o CCLD
> gnutls-serv.exe serv.o(.text+0x369): In function `human_addr': 
> d:/usr/eli/utils/gnutls-3.0.9/src/serv.c:620: undefined reference to
> `getnameinfo' 
> serv.o(.text+0x3cb):d:/usr/eli/utils/gnutls-3.0.9/src/serv.c:633:
> undefined reference to `getnameinfo' serv.o(.text+0x617): In function
> `listen_socket': d:/usr/eli/utils/gnutls-3.0.9/src/serv.c:697:
> undefined reference to `getaddrinfo' 
> serv.o(.text+0x7ce):d:/usr/eli/utils/gnutls-3.0.9/src/serv.c:776:
> undefined reference to `freeaddrinfo'
> 
> This happens because the prototypes of getnameinfo and getaddrinfo 
> (actually, their #define's to w32 API functions) in ws2tcpip.h are 
> not visible in w32api headers unless _WIN32_WINNT >= 0x0501.  (The 
> fallback implementation provided by MS in wspapi.h is not available 
> for MinGW.) My solution was to set _WIN32_WINNT on the Make command
> line: make DEFS='-DHAVE_CONFIG_H -D_WIN32_WINNT=0x0501' However, I
> believe that the build on Windows should set _WIN32_WINNT by default,
> since that's the only way to build GnuTLS with MinGW, AFAICS.



I've added the gnulib module getaddrinfo that contains those functions. 
It uses a different way (through GetProcAddress) to find those functions 
in windows but should be equivalent.

> Problem #5: Compilation of doc/printlist.c fails:

...

> and many more similar errors.
> The reason is that doc/Makefile.in used a literal "printlist" without
> $(EXEEXT), and therefore Make invokes default rules to build
> programs.  My solution was to edit Makefile.in to add the missing
> $(EXEEXT).


It looks like an automake bug then. Anyway I've disable this build
(already in 3.0.11) for windows so this should e ok.

> Problem #6: Failure to compile crywrap:
> 
[...]

> 

> and many more similar errors.
> 
> Crywrap is completely non-portable to Windows and cannot possibly 
> compile with MinGW.  I think the Windows build should simply skip it,
> as it is an non-essential component of GnuTLS.


Indeed. It is no longer compiled in 3.0.11 for windows.

> The rest of the problems are related to the test suite.
> Problem #7: "make check" fails in `tests' while compiling test 
> programs:


You should try 3.0.11 because not only tests were fixed but also
some internal library fixes (for openpgp) were done to make it work
in windows.

> This happens because tests/Makefile.in does not add libgnu.a after 
> libutils.a, which obviously needs it, at least on systems whose 
> vsnprintf is replaced by gnulib's one.  My solution was to add the 
> missing library:
> LDADD = ../lib/libgnutls.la \ ../gl/libgnu.la \ libutils.la \ 

> ../gl/libgnu.la \       <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< 

> $(LTLIBGCRYPT)	\ $(LIBSOCKET) $(INET_NTOP_LIB) $(INET_PTON_LIB)

I've solved that and should be ok in 3.0.11 in a similar way.

> Problem #8: Compilation of tests/openpgp-auth2.c fails:

Indeed, it is now skipped in windows.

> Problem #9: Compilation of tests/slow/gendh.c fails:
> 
> This happens because GCC, at least on Windows, doesn't like trailing
> slashes in the directories mention in the -I switch. Solution: remove
> the slash:
> 
> AM_CPPFLAGS = \ -I$(top_srcdir)/lib/includes		\ 
> -I$(top_builddir)/lib/includes \ -I$(top_srcdir)/tests/
> <<<<<<<<<<<<<<<<<<<


Done.

> CCLD   gnutls-serv.exe Info: resolving _nettle_arcfour_crypt by
> linking to __imp__nettle_arcfour_crypt (auto-import)
> (there were a lot of these in many places).  I understand that this 
> means the linker resolved a function by linking against a DLL, but 
> perhaps some compiler or linker switch could prevent these warnings 
> from being emitted in the first place.


I don't know what this warning means or does. How would you fix it?

> Another group of warnings looked like this:
> CCLD   libexamples.la libtool: link: warning: `-no-install' is
> ignored for i686-pc-mingw32 libtool: link: warning: assuming
> `-no-fast-install' instead

...
> Only by digging deep inside libtool did I understand that this is 
> probably harmless, as Windows indeed does not support -no-install. 
> But I think the build should avoid using -no-install on Windows by 
> default.

This one I don't know if it is correct to remove it. I think that 
Libtool shouldn't emit this warning if no-install is ignored for the 
windows platform. Otherwise we'll have to know which platforms support
it or not, and because we don't want to care about it is the reason we 
use libtool anyway :)

> This is all.  Hope this will be useful.


Thank you for this information. I've updated the git with your suggested fixes.


regards,
Nikos