bug#10474: Building guile 2.x under mingw + msys

[Eli Zaretskii <eliz@gnu.org>]

> From: Andy Wingo <wingo@pobox.com>
> Cc: ludo@gnu.org,  10474@debbugs.gnu.org
> Date: Tue, 19 Feb 2013 22:39:01 +0100
> 
> Sorry for the large number of mails.

Don't worry about that.

> > 	Avoid compiler warnings on MS-Windows.
> >
> > 	* libguile/print.c (display_string_using_iconv): Cast 2nd arg of
> > 	`iconv' to `const char **', to avoid compiler warnings.
> >
> > 	* libguile/ports.c (get_iconv_codepoint): Cast 2nd arg of `iconv'
> > 	to `const char **', to avoid compiler warnings.
> >
> >
> > --- libguile/print.c~0	2011-10-08 01:49:48.000000000 +0200
> > +++ libguile/print.c	2012-01-15 15:10:51.450848400 +0200
> > @@ -899,7 +899,7 @@ display_string_using_iconv (const void *
> >        output = encoded_output;
> >        output_left = sizeof (encoded_output);
> >  
> > -      done = iconv (pt->output_cd, &input, &input_left,
> > +      done = iconv (pt->output_cd, (const char **)&input, &input_left,
> >  		    &output, &output_left);
> >  
> >        output_len = sizeof (encoded_output) - output_left;
> >
> >
> > --- libguile/ports.c~0	2011-10-08 01:49:48.000000000 +0200
> > +++ libguile/ports.c	2012-01-15 15:11:11.856706600 +0200
> > @@ -1305,7 +1305,7 @@ get_iconv_codepoint (SCM port, scm_t_wch
> >        input_left = bytes_consumed + 1;
> >        output_left = sizeof (utf8_buf);
> >  
> > -      done = iconv (pt->input_cd, &input, &input_left,
> > +      done = iconv (pt->input_cd, (const char **)&input, &input_left,
> >  		    &output, &output_left);
> >        if (done == (size_t) -1)
> >  	{
> >
> 
> However iconv is specified
> (http://pubs.opengroup.org/onlinepubs/009695399/functions/iconv.html) to
> take a char** as the first argument.  Don't we end up using a GNU iconv
> on mingw32 anyway?

Yes, we do use GNU iconv.  However, the version of iconv.h (from GNU
iconv version 1.13, I think) that I have declares the function like
this:

  extern size_t iconv (iconv_t cd, const char* * inbuf, size_t *inbytesleft, char* * outbuf, size_t *outbytesleft);

> > 	(make_objcode_from_file): Zero out errno before calling full_read,
> > 	to make sure the value after the call reflects errors inside
> > 	full_read.
> 
> This seems like a bug to me, that the behavior of full_read can depend
> on the incoming errno.  I mailed bug-gnulib and put you on copy to see
> what they would say.

As I wrote there, I suggest to add some application-level diagnostics
in this case, something like "premature end of file".

> > 	* libguile/mkstemp.c (O_BINARY): Define for all platforms.
> > 	(mkstemp): Open the temporary file in binary mode, so that
> > 	compiled *.go files are written verbatim on MS-Windows.
> 
> Hummmmmmm.  It's true that the only user of mkstemp in Guile is the
> compilation code.  OTOH it's a public interface, and this change might
> affect someone.  OTOH MinGW is not well-served currently and probably
> there are ~0 active users.  Any other thoughts here?

An alternative would be to provide a public interface to switch an
existing file descriptor to binary mode, and then use it from the code
that calls mkstemp to output what will eventually become a *.go file.

> > 	* libguile/net_db.c [HAVE_WINSOCK2_H]: Add !GNULIB_TEST_SOCKET to
> > 	the condition, to include sys/socket.h and netdb.h when gnulib's
> > 	socket module is being used.  Fixes compiler warnings and errors
> > 	on MS-Windows.
> >
> > 	* libguile/socket.c: Likewise.
> >
> >
> > --- libguile/net_db.c~0	2011-07-07 02:49:59.000000000 +0300
> > +++ libguile/net_db.c	2012-01-15 16:22:56.366898100 +0200
> > @@ -49,8 +49,11 @@
> >  
> >  #include <sys/types.h>
> >  
> > -#ifdef HAVE_WINSOCK2_H
> > +#if HAVE_WINSOCK2_H && !GNULIB_TEST_SOCKET
> >  #include <winsock2.h>
> > +# if HAVE_WS2TCPIP_H
> > +#  include <ws2tcpip.h>
> > +# endif
> >  #else
> >  #include <sys/socket.h>
> >  #include <netdb.h>
> 
> Surely we should just rely on Gnulib here and not include the winsock
> headers.  In what condition would these headers be included otherwise?
> A visual studio build or something?

Sorry, I have no idea.  If relying on gnulib is OK for non-MinGW
Windows platforms (if there are such), then it's fine with me.