[Help-gnutls] Re: Build gnutls on windows

[Simon Josefsson]

Martin Lambers <marlam at marlam.de> writes:

> On Mon, 19. Sep 2005, 23:45:41 +0200, Simon Josefsson wrote:
>> Can you test whether:
>> 
>> http://josefsson.org/daily/gnutls/gnutls-20050919.tar.gz
>> 
>> build correctly for you?
>
> It does not, but the changes required to make it build correctly are
> small:

Thanks for testing!

> 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 configure.ac 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 think the simplest solutions is to stop using the error module in
src/... I have made this change in CVS now, and applied your fix to
remove setting program_name in the core library too.

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

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

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

I'll bring up the header issue on the gnulib list.  If it is solved,
the examples will link to gnulib and we can also use gnulib's
inet_ntop module.  If it is not solved, we disable the examples on
platforms that lack sys/socket.h.

It would be useful to go over the #ifdef WIN32's in src/ too, and make
them go away.  Would you like to take a stab at it?

> The changes 1 and 2 may be useful nevertheless; I can send a patch with
> only these changes if you wish.

Yes, please do!  Only for 1 and 2.

Thanks,
Simon