GNU bug report logs -
#10474
Building guile 2.x under mingw + msys
Previous Next
Reported by: Andy Wingo <wingo <at> pobox.com>
Date: Tue, 10 Jan 2012 21:59:02 UTC
Severity: normal
Done: Andy Wingo <wingo <at> pobox.com>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
> From: Andy Wingo <wingo <at> pobox.com>
> Cc: ludo <at> gnu.org, 10474 <at> 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.
This bug report was last modified 12 years and 93 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.