[gnutls-devel] Building a MinGW port of GnuTLS 3.4.15

[Nikos Mavrogiannopoulos]

On Tue, Oct 4, 2016 at 1:09 PM, Eli Zaretskii <eliz at gnu.org> wrote:
> I've built and tested this version natively on MS-Windows using
> mingw.org's MinGW tools.  I've bumped into some issues which I'd like
> to report here:
>
> 1. There are relatively many compilation warnings, triggered by the
>    warning options passed to the compiler.  I think most of the
>    warnings are not Windows-specific.  I wonder if all of these
>    switches are appropriate for production builds.  Some examples
>    of the warnings include:
>    . unused variables
>    . comparison between signed and unsigned
>    . stack frame size is larger than 2048 bytes (why such a low limit,
>      when on modern platforms a program's stack size is something like
>      2MB?)

That was added mainly to allow gnutls to run on platforms with limited
memory. I also consider using too much stack in a library an issue,
since memory errors due to stack exhaustion cannot be caught by the
calling application and result to a crash. Currently the stack usage
warnings are on legacy code which will be hopefully at some point
removed.

>    . mismatch in signedness between prototype and actual arguments

If that's on the main library code, I'd appreciate pointing them.

>    . "cannot optimize loop, the loop counter may overflow"

These warnings I have not been able to eliminate. I could not see
reasonable conditions of overflowing but I could be wrong.

> 2. system-keys-win.c was written using features that are available
>    with the MinGW64 toolchain, but not with mingw.org's one.  I needed
>    to add the missing stuff by hand; see the patch below.

I've included this patch, though I'm not sure we should carry too much
legacy code. Is there are reason you don't use mingw64?

> 3. libgnutls fails to link due to unresolved external rpl_fseek:
>
>        CCLD     libgnutls.la
>      opencdk/.libs/libminiopencdk.a(armor.o): In function `armor_decode':
>      d:\gnu\gnutls-3.4.15\lib\opencdk/armor.c:232: undefined reference to `rpl_fseek'
>      opencdk/.libs/libminiopencdk.a(stream.o): In function `cdk_stream_seek':
>      d:\gnu\gnutls-3.4.15\lib\opencdk/stream.c:1081: undefined reference to `rpl_fseek'
>    I reported this for 3.3.11 back in Dec 2014.

I do not know about this issue or what could trigger it. Note that
builds for windows32/64 are included in our CI and they seem to work
well under wine.
For tagged releases you can see the build process and download the
produced dlls in the builds pages like:
https://gitlab.com/gnutls/gnutls/commit/64fd6aa9e7c38b645c710aac036d4c5bd08b0b0c/builds
(I have not found a way to link to a particular tag dlls directly)

> 4. certuniqueid.c in the test suite uses %zd, which is not supported
>    by the Windows runtime.

Thanks. These were removed.

> 5. Test programs fail to run because they don't find the libgnutls
>    shared library (which was not installed yet).  I fixed that by
>    manually adding the directories with the DLLs to PATH, but I think
>    the test suite should do that, because if a previous version of the
>    same DLL is installed, the tests will silently use it instead of
>    the one in the source tree, which might cause incorrect results and
>    subtle failures.

That does not seem to be the case in the mingw builds under fedora as
shown above. Could that be something related to mingw vs mingw64?

> 6. "make install-strip" installs the *.def files in the ${prefix}/bin
>    directory, whereas it should install them in ${prefix}/lib, I
>    think.

No opinion about that. I have no idea what are the conventions for win
libraries. If you think that libdir is a better location I'll update
the Makefile.am.

> 7. The *.def file for the produced libgnutls-openssl-27.dll is
>     libgnutls-openssl-30.def, for some reason.  Which version number
>     is correct for libgnutls-openssl, 27 or 30?

It is 27. There seems to be some assumption in the makefile that these
are equal. Corrected.

> 8. benchmark.c doesn't declare the MS-Windows variant of alarm_handler
>    'static', which causes a warning converted to error by the compiler
>    switches, and stops the compilation.

Fixed.

> 9. certtool-cfg.c doesn't include the Gnulib-provided arpa/inet.h
>    header, which triggers warnings about inet_pton missing a
>    declaration.

Fixed.

> 11.tests/utils.c lacks the 'sleep' function, which is needed for
>    MinGW, as the Windows runtime lacks it.

Could that be something that mingw64 added as macro or so? I was also
wondering how that works under mingw.

regards,
Nikos