bug-guile
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Andy Wingo
Subject: bug#10474: Building guile 2.x under mingw + msys
Date: Tue, 19 Feb 2013 22:39:01 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2 (gnu/linux)

Hi Eli,

Sorry for the large number of mails.

You sent this patch:

On Thu 02 Feb 2012 18:34, Eli Zaretskii <address@hidden> 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?

>       * libguile/deprecation.c (vsnprintf) [__MINGW32__]: Don't redefine
>       if already defined.  Avoids compiler warnings.
>
> --- libguile/deprecation.c~0  2011-07-07 02:49:59.000000000 +0300
> +++ libguile/deprecation.c    2012-01-15 14:48:55.966092400 +0200
> @@ -36,7 +36,7 @@
>  
>  
>  /* Windows defines. */
> -#ifdef __MINGW32__
> +#if defined (__MINGW32__) && !defined (vsnprintf)
>  #define vsnprintf _vsnprintf
>  #endif

It seems that gnulib handles this already, and this block is no longer
present in Guile source (since last January).

>       * libguile/filesys.c (mkdir) [__MINGW32__]: Don't redefine if
>       GNULIB_defined_rpl_mkdir is defined, meaning that the gnulib
>       replacement is being used.
>       (fchmod) [__MINGW32__]: Define to zero, to avoid gratuitous failures
>       of many file operations on MS-Windows.
>
> --- libguile/filesys.c~0      2011-10-08 01:49:48.000000000 +0200
> +++ libguile/filesys.c        2012-01-18 08:29:49.629722000 +0200
> @@ -116,11 +116,24 @@
>  
>  /* Some more definitions for the native Windows port. */
>  #ifdef __MINGW32__
> -# define mkdir(path, mode) mkdir (path)
> +/* When configured to use the gnulib replacement, don't redefine
> +   mkdir, as it is already redirected to the replacement, see
> +   lib/sys/stat.h.  */
> +# if !GNULIB_defined_rpl_mkdir
> +#  define mkdir(path, mode) mkdir (path)
> +# endif
>  # define fsync(fd) _commit (fd)
> -# define fchmod(fd, mode) (-1)
> +# define fchmod(fd, mode) (0)
>  #endif /* __MINGW32__ */

Likewise, this block is no longer present in Guile; we depend on Gnulib
for mkdir, and we have an explicit check for fchmod.

> +#ifndef O_BINARY
> +# ifdef _O_BINARY
> +#  define O_BINARY _O_BINARY
> +# else
> +#  define O_BINARY 0
> +# endif
> +#endif
> +

I assume this won't be needed for filesys.c, as it does not use
O_BINARY (any more?).

>       Read and write *.go files and copy files in binary mode on
>       MS-Windows.
>
>       * libguile/objcodes.c (O_BINARY): Define on all platforms.

Gnulib's fcntl.h defines O_BINARY on all platforms already, so this
should be fixed already.

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

>       (scm_load_objcode): Open objcode files in binary mode, so that
>       *.go files are read verbatim on MS-Windows.

Applied, thanks.

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

>       * libguile/filesys.c (O_BINARY): Define for all platforms.
>       (scm_copy_file): Use O_BINARY in the call to open_or_open64.

Applied, thanks.


>       Fix compilation warnings and errors on MS-Windows when
>       compiling network-related code due to missing macros and
>       prototypes.
>
>       * 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?

Regards,

Andy
-- 
http://wingolog.org/





reply via email to

[Prev in Thread] Current Thread [Next in Thread]