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

[Eli Zaretskii]

> From: Nikos Mavrogiannopoulos <nmav at gnutls.org>
> Date: Wed, 5 Oct 2016 08:50:19 +0200
> Cc: GnuTLS development list <gnutls-devel at lists.gnutls.org>
> 
> >    . 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.

I understand the concern for the stack usage, but 2KB sounds awfully
low by modern standards.  If this is for special-purpose platforms,
perhaps the warning should be turned on only on those platforms?

> >    . mismatch in signedness between prototype and actual arguments
> 
> If that's on the main library code, I'd appreciate pointing them.

I will show the full list of these warnings for library code in a
separate message.

> >    . "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.

I agree, but then maybe this warning option shouldn't be used, as it
produces too many false positives?

> > 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.

mingw.org is still developing its MinGW, albeit not as actively as
MinGW64.  So it's hardly "legacy", at least not yet.

> Is there are reason you don't use mingw64?

Yes, I don't trust their QA.  Besides, switching from a well-tuned and
fully operational and proven development environment to a subtly
incompatible environment should be for a very good reason, and I don't
yet have such a reason.

> > 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.

I'm sure I explained it back then: This is because gl/libgnu.a does
not compile fseek replacement in src/gl/fseek.c and src/gl/fseeko.c
(unlike src/gl/libgnu.a), but gl/stdio.h defines fseek to rpl_fseek,
which is defined in src/gl/fseek.c.

Let me know if something is still unclear about this.

> Note that builds for windows32/64 are included in our CI and they
> seem to work well under wine.

This issue depends on the configure-time tests, so perhaps they are
different in your cross-compiled environment.

> > 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?

No, it can't, AFAIK.  It's a general Windows issue: a DLL is looked
according to certain rules and order described here:

 https://msdn.microsoft.com/en-us/library/windows/desktop/ms682586(v=vs.85).aspx

(only the "Desktop applications" part is relevant for this
discussion).  In a nutshell, Windows first looks in the same directory
where the .exe file lives, then in the current directory, then along
the PATH (the other places are not relevant for this case).  The
just-built libgnutls DLL is in neither of these.

I don't think MinGW64 could affect this because this search happens
before the application code starts, it is part of the process of
loading the application by the Windows loader.

> > 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.

bindir is definitely wrong.  The other *.def files I have are in
libdir, so yes, I think it's a better place.

> > 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?

It looks like MinGW64 has it as a function in their add-on runtime
library, so only mingw.org needs that.

The way to discern between these two MinGW flavors is a bit tricky,
and is shown in the patch for system-keys-win.c:

#ifdef __MINGW32__
# include <_mingw.h>
# ifdef __MINGW64_VERSION_MAJOR
/* MinGW64 stuff */
# else
/* mingw.org stuff */
# endif
#endif

Btw, one other annoyance with warnings is this:

       CCLD     libexamples.la
     libtool: link: warning: `-no-install' is ignored for i686-pc-mingw32
     libtool: link: warning: assuming `-no-fast-install' instead

AFAIR, it is issued for every example and test program.

Thanks for the fixes, they will definitely make building GnuTLS easier
next time.