[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Help-gnutls] Re: Build gnutls on windows

From: Martin Lambers
Subject: Re: [Help-gnutls] Re: Build gnutls on windows
Date: Thu, 22 Sep 2005 23:15:02 +0200
User-agent: Mutt/1.5.6+20040907i

On Wed, 21. Sep 2005, 22:44:57 +0200, Simon Josefsson wrote:
> > The first patch removes 'char *program_name = "gnutls";' from
> > lib/gnutls_global.c. This apparently reverts a change from 2005-08-30.
> > I did not get the missing symbols error afterwards. When does it cause
> > problems for you?
> I had problems with this on uClinux too...  The problem is that the
> error module from gnulib use program_name, but the core GnuTLS library
> does not use the error module.  On some systems, the core library will
> not link because program_name is not present.  The error module is
> only used by some code in src/.
> There has been discussion on solving this on the gnulib list, i.e.,
> having two different gnulib directories, one for the library in lib/
> and one for the application in src/.  This would also make it possible
> to use GPL'd gnulib modules in src/, without causing license problems
> in lib/.  Currently the only solution is to create a in
> lib/ and build it separately.  This is what I did in GNU SASL, but I
> don't want to do the same for GnuTLS.

I've been following that discussion loosely, but now I realize how
useful two different directories could be.

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

> > 3. Include a different header on WIN32.
> > 4. Use inet_ntoa instead of inet_ntop on WIN32.
> No... There should be gnulib modules to handle this silliness.  There
> already is a inet_ntop gnulib module.  There could be a gnulib module
> that provided sys/socket.h, netinet/in.h and arpa/inet.h on platforms
> that doesn't have them.  For mingw32, those files could simply include
> winsock2.h if that is indeed the proper way to get access to POSIX
> functionality.

Unfortunately, every single socket function on Win32 is incompatible
with POSIX in some way (or so it seems). Sometimes it's obvious,
sometimes not.
- errno is never set
- The "network library" must be initialized and closed with special
- 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.

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

BTW, the unlink() and fcntl() examples are not yet handled by plibc as
far as I can tell.


Attachment: gnutls-example_changes.patch
Description: Text document

reply via email to

[Prev in Thread] Current Thread [Next in Thread]