unofficial mirror of bug-guile@gnu.org 
 help / color / mirror / Atom feed
From: Andy Wingo <wingo@pobox.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: ludo@gnu.org, 10474@debbugs.gnu.org
Subject: bug#10474: Building guile 2.x under mingw + msys
Date: Wed, 20 Feb 2013 22:57:18 +0100	[thread overview]
Message-ID: <87y5eisl6p.fsf@pobox.com> (raw)
In-Reply-To: <83ip5mokzx.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 20 Feb 2013 21:14:58 +0200")

Hi Eli,

On Wed 20 Feb 2013 20:14, Eli Zaretskii <eliz@gnu.org> writes:

>> > 	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);

In these files, `input' is a char*.  So &input should be a char**.
Shouldn't that cast to const char** without a warning?

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

You know, given that temporary files are for writing more than for
reading, it makes sense to just add the O_BINARY flag and be done with
it.  I'll do that.

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

I think for now this is the right thing.  It seems that even visual
studio builds are supported by gnulib, so the specs we code against
should either be posix or gnulib abstractions.  I have removed this #if
block.

Thanks,

Andy
-- 
http://wingolog.org/





  reply	other threads:[~2013-02-20 21:57 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CAL+StqnixLW+QwOP2BpZrjnz1wAQjnio9H6P=VM=9Cnn-B2-ng@mail.gmail.com>
2012-01-10 22:00 ` bug#10474: Building guile 2.x under mingw + msys Andy Wingo
     [not found] ` <87pqerdxq4.fsf@pobox.com>
2012-01-17  8:09   ` Eli Zaretskii
2012-01-17 18:14     ` Eli Zaretskii
2012-01-18 23:55       ` Ludovic Courtès
2012-01-19  4:04         ` Eli Zaretskii
2012-02-02  0:59           ` Andy Wingo
2012-02-02  3:53             ` Eli Zaretskii
2012-02-02 16:39             ` Ludovic Courtès
2012-02-02 17:14               ` Eli Zaretskii
2012-02-02 17:34             ` Eli Zaretskii
2013-02-18 18:10               ` Andy Wingo
2013-02-18 19:56                 ` Eli Zaretskii
2013-02-19 10:44               ` Andy Wingo
2013-02-19 12:55                 ` Ludovic Courtès
2013-02-19 13:39                   ` Andy Wingo
2013-02-19 17:53                 ` Eli Zaretskii
2013-02-19 21:44                   ` Andy Wingo
2013-02-20 19:16                     ` Eli Zaretskii
2013-02-24 12:08                   ` Andy Wingo
2013-02-19 15:47               ` Andy Wingo
2013-02-19 18:00                 ` Eli Zaretskii
2013-02-24 13:25                   ` Andy Wingo
2013-02-24 15:43                     ` Eli Zaretskii
2013-05-07 17:18                     ` bug#14361: Building guile 2.0.9 " Eli Zaretskii
2016-06-20 21:19                       ` Andy Wingo
2016-06-21 12:46                         ` Eli Zaretskii
2016-06-21 15:06                           ` Andy Wingo
2016-06-21 15:42                             ` Eli Zaretskii
2016-06-21 20:52                               ` Andy Wingo
2016-06-24  9:51                                 ` Eli Zaretskii
2013-02-19 21:39               ` bug#10474: Building guile 2.x " Andy Wingo
2013-02-20 19:14                 ` Eli Zaretskii
2013-02-20 21:57                   ` Andy Wingo [this message]
2013-02-21  3:49                     ` Eli Zaretskii
2013-02-21  8:18                       ` Andy Wingo
2012-01-19 17:35         ` Eli Zaretskii
2012-01-21 11:09           ` Eli Zaretskii
2012-01-24 12:27             ` Eli Zaretskii
2012-01-25 21:12             ` Ludovic Courtès
2012-01-26  5:37               ` Eli Zaretskii
2012-01-29 18:30                 ` Ludovic Courtès
2012-01-29 19:17                   ` Eli Zaretskii
2012-01-29 22:56                     ` Ludovic Courtès
2012-01-10 21:58 Andy Wingo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/guile/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87y5eisl6p.fsf@pobox.com \
    --to=wingo@pobox.com \
    --cc=10474@debbugs.gnu.org \
    --cc=eliz@gnu.org \
    --cc=ludo@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).