[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#10474: Building guile 2.x under mingw + msys
From: |
Eli Zaretskii |
Subject: |
bug#10474: Building guile 2.x under mingw + msys |
Date: |
Wed, 20 Feb 2013 21:14:58 +0200 |
> From: Andy Wingo <address@hidden>
> Cc: address@hidden, address@hidden
> 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.
- bug#10474: Building guile 2.x under mingw + msys, (continued)
bug#10474: Building guile 2.x under mingw + msys, Andy Wingo, 2013/02/19
bug#10474: Building guile 2.x under mingw + msys, Andy Wingo, 2013/02/19
- bug#10474: Building guile 2.x under mingw + msys,
Eli Zaretskii <=