[Help-gnutls] Re: Build gnutls on windows

[Simon Josefsson]

Martin Lambers <marlam at marlam.de> writes:

>> > The second patch changes the example code in doc/examples:
>> > 1. Replace bzero with memset.
>> > 2. Don't use mmap (this is the same change that was done in src/cli.c).
>> 
>> Ok.
>
> I attached a patch wich contains only these changes.

Applied, many thanks!

> Unfortunately, every single socket function on Win32 is incompatible
> with POSIX in some way (or so it seems). Sometimes it's obvious,
> sometimes not.
> Examples: 
> - errno is never set
> - The "network library" must be initialized and closed with special
>   functions
> - Sockets cannot just be closed with close(), they need closesocket()
> - shutdown() uses non-standard constants
> - You cannot use fcntl() on a socket. There's only a limited
>   ioctlsocket() function.

Ouch.  So while cross-compiling to mingw32 now work without link
failures, there will be subtle problems when the resulting binary is
used.

>> > But maybe it would be better to disable compilation of the examples on
>> > Win32 instead of cluttering example code with #ifdefs.
>> 
>> Exactly.  We should stop cluttering code with #ifdef's.  We should
>> write code that works best on the GNU platform, and use gnulib modules
>> where the native system is failing.
>
> You're right. I'll keep that in mind.
>
> However, this could mean to drop support for MinGW: I doubt that gnulib
> is the best way to achieve reasonable POSIX support on Win32.
>
> An unlink() replacement that delays the actual unlink operation until
> all file descriptors referring to the file are closed is one example:
> such a function is not easy to write on Win32. The same holds for
> using standard functions like fcntl() or even close() on sockets.
>
> Programs that are expected to work on Win32 often avoid to rely on basic
> standardized functionality like this. Such code does not qualify for
> "works best on the GNU platform" anymore.
>
> Reasonable POSIX support on Win32 is not just a collection of fixes for
> minor misbehaviour; it is a major task. Perhaps it would be better to
> leave that to an external project and only support "MinGW + plibc" (or
> something similar) as a target platform.

Yes, I think you are right.  However, it isn't impossible to integrate
something like plibc in gnulib, or in GnuTLS itself.  Then the GnuTLS
core code will be good and the resulting binaries should run properly
too.  I'm not sure GnuTLS need a lot from POSIX, perhaps we can even
integrate the plibc functions we need in GnuTLS.

Btw, have you tested to run a mingw32 built gnutls-cli on a Windows
platform?  It shouldn't be too hard to test it to see whether it works
or almost works.

Thanks,
Simon