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

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

[Andy Wingo]

Hi Commander Sirow,

On Tue 03 Jan 2012 16:46, Commander Sirow <commander.sirow@googlemail.com> writes:

> so I've been trying to build guile 2.0.3 from source with mingw (gcc 4.6.2) + msys.

Thanks for the report!  There are enough things to track down here that
I opened a bug report, and put you on the Cc.

On Tue 03 Jan 2012 16:46, Commander Sirow <commander.sirow@googlemail.com> writes:

> make[3]: Entering directory `/home/Commander/guile-2.0.3/libguile'
>   GEN    guile-procedures.texi
> Throw without catch before boot:
> Throw to key system-error with args ("canonicalize-path" "~A" ("No such file or
> directory") (2))Aborting.

AIUI the canonicalize_path binding that gnulib provides for mingw ends
up shelling out to `rm' and other commands.  They claim that it is
reasonable to install these on a mingw system; I don't know.  But is it
possible that you don't have these files?

See http://thread.gmane.org/gmane.comp.lib.gnulib.bugs/25451/focus=25466.

> Throw to key misc-error with args ("primitive-load-path" "Unable to find file ~S
>  in load path" ("ice-9/boot-9") #f)Aborting.

Let's deal with the first one first.

Regards,

Andy
-- 
http://wingolog.org/

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

[Eli Zaretskii]

[I removed guile-user@gnu.org from the CC list; let me know if that is
not TRT.]

> Date: Tue, 10 Jan 2012 23:00:35 +0100
> Cc: guile-user@gnu.org, 10474@debbugs.gnu.org
> 
> > so I've been trying to build guile 2.0.3 from source with mingw (gcc 4.6.2) + msys.
> 
> Thanks for the report!

I have a similar, although slightly different in details, experience.
(I will post the details as soon as the saga is finished for me and I
have all it figured out ;-)

> > make[3]: Entering directory `/home/Commander/guile-2.0.3/libguile'
> >   GEN    guile-procedures.texi
> > Throw without catch before boot:
> > Throw to key system-error with args ("canonicalize-path" "~A" ("No such file or
> > directory") (2))Aborting.
> 
> AIUI the canonicalize_path binding that gnulib provides for mingw ends
> up shelling out to `rm' and other commands.

I don't think this is true; at least I don't see any such shelling out
in lib/canonicalize-lgpl.c, which I believe is the module you allude
to.

The problem, AFAIK, is entirely different and quite mundane:
canonicalize_file_name simply does not support Windows-style
D:/foo/bar file names, nor does it support backslashes as separators
in file names.

My evidence is that I added an fprintf to canonicalize-path where it
calls canonicalize_file_name, and the file name passed to it was
entirely reasonable, something like

   D:\path\to\guile-2.03/module/ice-9/boot-9.scm

(or some such, I'm writing this from my faulty memory).

I think I know how to fix canonicalize_file_name, and I will send a
tentative patch later, perhaps even today, when I have it working and
get past this abort.

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

[Eli Zaretskii]

> Date: Tue, 17 Jan 2012 10:09:21 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> CC: commander.sirow@googlemail.com, 10474@debbugs.gnu.org
> 
> The problem, AFAIK, is entirely different and quite mundane:
> canonicalize_file_name simply does not support Windows-style
> D:/foo/bar file names, nor does it support backslashes as separators
> in file names.
> 
> My evidence is that I added an fprintf to canonicalize-path where it
> calls canonicalize_file_name, and the file name passed to it was
> entirely reasonable, something like
> 
>    D:\path\to\guile-2.03/module/ice-9/boot-9.scm
> 
> (or some such, I'm writing this from my faulty memory).
> 
> I think I know how to fix canonicalize_file_name, and I will send a
> tentative patch later, perhaps even today, when I have it working and
> get past this abort.

The patch to fix canonicalize_file_name is below.  It gets me through
the "GEN guile-procedures.texi" step.

The next failure is this:

       GEN    guile-procedures.texi
     Backtrace:
     In unknown file:
	?: 3 [boot-closure #t #<catch-closure 2903300> ...]
	?: 2 [catch-closure]
	?: 1 [primitive-eval ((@ # %) (begin # # #))]
	?: 0 [primitive-load-path "d:\\usr\\eli\\utils\\guile-2.0.3\\libguile/d:/usr/eli/utils/guile-2.0.3/meta/guild"]

     ERROR: In procedure primitive-load-path:
     ERROR: In procedure canonicalize-path: No such file or directory

which again looks like failure to treat d:/foo/bar file names as
absolute.

Some random poking around reveals this in ice-9/boot-9.scm:

    (define (absolute-path? path)
      (string-prefix? "/" path))

which looks a likely culprit.  Changing it to recognize d:/foo/bar
absolute file names indeed solves this problem.  (I'm too embarrassed
to show the changes I did for that, as I know nothing about Scheme,
and my code is too ugly to go into upstream.  I don't even know how to
condition the change on the underlying platform being MS-Windows.)

The next problem is here:

       GUILEC ice-9/eval.go
     Backtrace:
     In unknown file:
	?: 5 [boot-closure #t #<catch-closure 231fd40> ...]
	?: 4 [catch-closure]
	?: 3 [primitive-eval ((@ # %) (begin # # #))]
	?: 2 [chmod #<input-output: ice-9/eval.go.9IiPxC 6> 438]
	?: 1 [boot-closure system-error "chmod" ...]
	?: 0 [delete-file "ice-9/eval.go.9IiPxC"]

     ERROR: In procedure delete-file:
     ERROR: In procedure delete-file: Permission denied

This happens because Guile calls fchmod, which is #define'd to -1 on
MinGW.

Solution: #define it to zero, since chmod is mostly a no-op on Windows
anyway.  This passes the eval.go step (and then fails while compiling
psyntax-pp.go; to be continued...).

As an aside, if this kind of operation is a frequent one, I'd suggest
to change the caller so that it never uses fchmod on MS-Windows,
because this function cannot be implemented there, except on the
latest versions (Windows 7 etc.).  Use chmod instead, even if that is
less efficient.

Btw, why doesn't the backtrace show file names, but says "unknown
file"?  Is this expected during the build, or is there another bug to
look for?  If the latter, any hints as to where to look for the
reason(s)?

Here's the patch for canonicalize-lgpl.c to make it Windows-friendly.
I will send it to the gnulib developers as well.

--- lib/canonicalize-lgpl.c~0	2011-10-22 16:19:34.000000000 +0200
+++ lib/canonicalize-lgpl.c	2012-01-17 13:10:52.608428500 +0200
@@ -51,6 +51,7 @@
 # define __realpath realpath
 # include "pathmax.h"
 # include "malloca.h"
+# include "dosname.h"
 # if HAVE_GETCWD
 #  if IN_RELOCWRAPPER
     /* When building the relocatable program wrapper, use the system's getcwd
@@ -101,6 +102,7 @@ __realpath (const char *name, char *reso
   const char *start, *end, *rpath_limit;
   long int path_max;
   int num_links = 0;
+  size_t prefix_len;
 
   if (name == NULL)
     {
@@ -143,7 +145,11 @@ __realpath (const char *name, char *reso
     rpath = resolved;
   rpath_limit = rpath + path_max;
 
-  if (name[0] != '/')
+  /* This is always zero for Posix hosts, but can be 2 for MS-Windows
+     and MS-DOS X:/foo/bar file names.  */
+  prefix_len = FILE_SYSTEM_PREFIX_LEN (name);
+
+  if (!IS_ABSOLUTE_FILE_NAME (name))
     {
       if (!__getcwd (rpath, path_max))
         {
@@ -154,13 +160,19 @@ __realpath (const char *name, char *reso
     }
   else
     {
-      rpath[0] = '/';
-      dest = rpath + 1;
-      if (DOUBLE_SLASH_IS_DISTINCT_ROOT && name[1] == '/')
+      dest = rpath;
+      if (prefix_len)
+	{
+	  memcpy (rpath, name, prefix_len);
+	  dest += prefix_len;
+	}
+      *dest++ = '/';
+      if (DOUBLE_SLASH_IS_DISTINCT_ROOT && ISSLASH (name[1])
+	  && !prefix_len)
         *dest++ = '/';
     }
 
-  for (start = end = name; *start; start = end)
+  for (start = end = name + prefix_len; *start; start = end)
     {
 #ifdef _LIBC
       struct stat64 st;
@@ -170,11 +182,11 @@ __realpath (const char *name, char *reso
       int n;
 
       /* Skip sequence of multiple path-separators.  */
-      while (*start == '/')
+      while (ISSLASH (*start))
         ++start;
 
       /* Find end of path component.  */
-      for (end = start; *end && *end != '/'; ++end)
+      for (end = start; *end && !ISSLASH (*end); ++end)
         /* Nothing.  */;
 
       if (end - start == 0)
@@ -184,7 +196,7 @@ __realpath (const char *name, char *reso
       else if (end - start == 2 && start[0] == '.' && start[1] == '.')
         {
           /* Back up to previous component, ignore if at root already.  */
-          if (dest > rpath + 1)
+          if (dest > rpath + prefix_len + 1)
             while ((--dest)[-1] != '/');
           if (DOUBLE_SLASH_IS_DISTINCT_ROOT && dest == rpath + 1
               && *dest == '/')
@@ -205,7 +217,7 @@ __realpath (const char *name, char *reso
               if (resolved)
                 {
                   __set_errno (ENAMETOOLONG);
-                  if (dest > rpath + 1)
+                  if (dest > rpath + prefix_len + 1)
                     dest--;
                   *dest = '\0';
                   goto error;
@@ -295,17 +307,25 @@ __realpath (const char *name, char *reso
               memmove (&extra_buf[n], end, len + 1);
               name = end = memcpy (extra_buf, buf, n);
 
-              if (buf[0] == '/')
+              if (IS_ABSOLUTE_FILE_NAME (buf))
                 {
-                  dest = rpath + 1;     /* It's an absolute symlink */
-                  if (DOUBLE_SLASH_IS_DISTINCT_ROOT && buf[1] == '/')
+		  size_t pfxlen = FILE_SYSTEM_PREFIX_LEN (buf);
+
+		  if (pfxlen)
+		    memcpy (rpath, buf, pfxlen);
+                  dest = rpath + pfxlen;     /* It's an absolute symlink.  */
+		  *dest++ = '/';
+                  if (DOUBLE_SLASH_IS_DISTINCT_ROOT && ISSLASH (buf[1])
+		      && pfxlen == 0)
                     *dest++ = '/';
+		  /* Install the new prefix to be in effect hereafter.  */
+		  prefix_len = pfxlen;
                 }
               else
                 {
                   /* Back up to previous component, ignore if at root
                      already: */
-                  if (dest > rpath + 1)
+                  if (dest > rpath + prefix_len + 1)
                     while ((--dest)[-1] != '/');
                   if (DOUBLE_SLASH_IS_DISTINCT_ROOT && dest == rpath + 1
                       && *dest == '/')
@@ -319,7 +339,7 @@ __realpath (const char *name, char *reso
             }
         }
     }
-  if (dest > rpath + 1 && dest[-1] == '/')
+  if (dest > rpath + prefix_len + 1 && dest[-1] == '/')
     --dest;
   if (DOUBLE_SLASH_IS_DISTINCT_ROOT && dest == rpath + 1 && *dest == '/')
     dest++;

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

[Ludovic Courtès]

Hi Eli,

Eli Zaretskii <eliz@gnu.org> skribis:

> The patch to fix canonicalize_file_name is below.

Can you send this one to bug-gnulib@gnu.org?  (All the code under lib/
comes from Gnulib.)

(The rest of your investigation is interesting!)

Thanks,
Ludo’.

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

[Eli Zaretskii]

> From: ludo@gnu.org (Ludovic Courtès)
> Cc: 10474@debbugs.gnu.org, wingo@pobox.com, commander.sirow@googlemail.com
> Date: Thu, 19 Jan 2012 00:55:31 +0100
> 
> Hi Eli,
> 
> Eli Zaretskii <eliz@gnu.org> skribis:
> 
> > The patch to fix canonicalize_file_name is below.
> 
> Can you send this one to bug-gnulib@gnu.org?

I already did, as promised in my message.

> (The rest of your investigation is interesting!)

I have more, will publish it today, probably.

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

[Eli Zaretskii]

> From: ludo@gnu.org (Ludovic Courtès)
> Cc: 10474@debbugs.gnu.org, wingo@pobox.com, commander.sirow@googlemail.com
> Date: Thu, 19 Jan 2012 00:55:31 +0100
> 
> Can you send this one to bug-gnulib@gnu.org?  (All the code under lib/
> comes from Gnulib.)

For the record, my report to bug-gnulib is here:

  http://lists.gnu.org/archive/html/bug-gnulib/2012-01/msg00253.html

> (The rest of your investigation is interesting!)

Here's some more ;-)

In the last episode, we stopped here:

       GUILEC ice-9/psyntax-pp.go
     Throw without catch before boot:
     Throw to key system-error with args ("make_objcode_from_file" "~A" ("No error") (0))Aborting.

It turns out that this happens because Guile reads and writes objcodes
from/to *.go files in text mode.  My solution was to use binary mode
in writing in mkstemp.c:

      fd = open (template, O_RDWR|O_BINARY|O_CREAT|O_EXCL, 0600);

and in reading in objcodes.c:load-objcode:

      fd = open (c_file, O_RDONLY | O_BINARY | O_CLOEXEC);

While the latter change looks as TRT in all cases, the former does
not: there's no guarantee that mkstemp! will be used only for
outputting *.go files.  It is probably best to have a wrapper around
mkstemp!, and use only that for writing to *.go files in compile.scm.

Next obstacle: Abort while compiling ice-9/poll.scm:

     In ice-9/eval.scm:
      389: 19 [eval # #]
      350: 18 [eval # #]
      434: 17 [lp (#<fluid 22>) ("")]
     In system/base/compile.scm:
      148: 16 [compile-file "ice-9/poll.scm" #:output-file ...]
       43: 15 [call-once #<procedure 184fa00 at system/base/compile.scm:56:5 ()>]
     In ice-9/boot-9.scm:
      184: 14 [with-throw-handler #t ...]
     In system/base/compile.scm:
       59: 13 [#<procedure 184f9e0 at system/base/compile.scm:58:9 ()>]
      151: 12 [#<procedure 184fa20 at system/base/compile.scm:149:8 (port)> #<input-output: ice-9/poll.go.LORZMf 6>]
      200: 11 [read-and-compile #<input: ice-9/poll.scm 5> #:from ...]
      212: 10 [lp (#) #<directory # 14ec900> #<directory # 14ec900>]
      178: 9 [lp (#<procedure compile-tree-il (x e opts)>) (eval-when # #) ...]
     In ice-9/boot-9.scm:
     2095: 8 [save-module-excursion #<procedure 1b9b2d0 at language/scheme/compile-tree-il.scm:29:3 ()>]
     In language/scheme/compile-tree-il.scm:
       31: 7 [#<procedure 1b9b2d0 at language/scheme/compile-tree-il.scm:29:3 ()>]
     In ./ice-9/psyntax.scm:
     1011: 6 [chi-top-sequence ((eval-when # #)) () ((top)) ...]
      898: 5 [scan ((eval-when # #)) () ((top)) ...]
      269: 4 [scan ((load-extension # "scm_init_poll")) () ((top)) ...]
     In unknown file:
	?: 3 [load-extension "libguile-2.0" "scm_init_poll"]
     In ice-9/boot-9.scm:
      115: 2 [#<procedure 184f9c0 at ice-9/boot-9.scm:110:6 (thrown-k . args)> misc-error ...]
     In unknown file:
	?: 1 [delete-file "ice-9/poll.go.LORZMf"]
     In ice-9/boot-9.scm:
      119: 0 [#<procedure 184f9c0 at ice-9/boot-9.scm:110:6 (thrown-k . args)> system-error ...]

     ice-9/boot-9.scm:119:20: In procedure #<procedure 184f9c0 at ice-9/boot-9.scm:110:6 (thrown-k . args)>:
     ice-9/boot-9.scm:119:20: In procedure delete-file: Permission denied
     make[2]: *** [ice-9/poll.go] Error 1

This happens because poll.scm does this:

     (eval-when (eval load compile)
       (load-extension (string-append "libguile-" (effective-version))
		       "scm_init_poll"))

while scm_init_poll has this snippet:

     static void
     scm_init_poll (void)
     {
     #if HAVE_POLL
       scm_c_define_gsubr ("primitive-poll", 4, 0, 0, scm_primitive_poll);
     #else
       scm_misc_error ("%init-poll", "`poll' unavailable on this platform", SCM_EOL);
     #endif

Since Windows doesn't HAVE_POLL, scm_misc_error throws an error.

It doesn't sound wise to fail the entire build procedure due to `poll'
being unavailable (AFAIK, not only MS-Windows lacks that library
function).  Maybe poll.scm should be compiled, or maybe it should do
some clever tricks around load-extension to avoid throwing an error at
compile time.  I'm not a Guile or Scheme person, so I cannot suggest a
good solution.

As a workaround, I used "make -k" to allow the build to continue past
this point.

There's another problem in the above backtrace: The form that catches
the thrown error cannot delete the temporary file
ice-9/poll.go.LORZMf, because it tries to delete a file that is still
open.  Changing call-with-output-file/atomic to close the temporary
file before deletion, like this:

     (define* (call-with-output-file/atomic filename proc #:optional reference)
       (let* ((template (string-append filename ".XXXXXX"))
	      (tmp (mkstemp! template)))
	 (call-once
	  (lambda ()
	    (with-throw-handler #t
	      (lambda ()
		(proc tmp)
		(chmod tmp (logand #o0666 (lognot (umask))))
		(close-port tmp)
		(rename-file template filename))
	      (lambda args
		(close-port tmp) ;; <<<<<<<<<<<<<<<<<<<<<<<<<<<
		(delete-file template)))))))

solves the problem, and we can now see the correct backtrace:

     Backtrace:
     In ice-9/eval.scm:
      389: 19 [eval # #]
      350: 18 [eval # #]
      389: 17 [eval # #]
      350: 16 [eval # #]
      434: 15 [lp (#<fluid 22>) ("")]
     In system/base/compile.scm:
      149: 14 [compile-file "ice-9/poll.scm" #:output-file ...]
       43: 13 [call-once #<procedure 17c84a0 at system/base/compile.scm:56:5 ()>]
     In ice-9/boot-9.scm:
      184: 12 [with-throw-handler #t ...]
     In system/base/compile.scm:
       59: 11 [#<procedure 17c8480 at system/base/compile.scm:58:9 ()>]
      152: 10 [#<procedure 17c84c0 at system/base/compile.scm:150:8 (port)> #<closed: file 0>]
      201: 9 [read-and-compile #<input: ice-9/poll.scm 5> #:from ...]
      213: 8 [lp (#) #<directory # 1bafca8> #<directory # 1bafca8>]
      179: 7 [lp (#<procedure compile-tree-il (x e opts)>) (eval-when # #) ...]
     In ice-9/boot-9.scm:
     2095: 6 [save-module-excursion #<procedure 185dea0 at language/scheme/compile-tree-il.scm:29:3 ()>]
     In language/scheme/compile-tree-il.scm:
       31: 5 [#<procedure 185dea0 at language/scheme/compile-tree-il.scm:29:3 ()>]
     In ./ice-9/psyntax.scm:
     1011: 4 [chi-top-sequence ((eval-when # #)) () ((top)) ...]
      898: 3 [scan ((eval-when # #)) () ((top)) ...]
      269: 2 [scan ((load-extension # "scm_init_poll")) () ((top)) ...]
     In unknown file:
	?: 1 [load-extension "libguile-2.0" "scm_init_poll"]
     In ice-9/boot-9.scm:
      119: 0 [#<procedure 17c8460 at ice-9/boot-9.scm:110:6 (thrown-k . args)> misc-error ...]

     ice-9/boot-9.scm:119:20: In procedure #<procedure 17c8460 at ice-9/boot-9.scm:110:6 (thrown-k . args)>:
     ice-9/boot-9.scm:119:20: In procedure %init-poll: `poll' unavailable on this platform

The build still stops, but now we have a human-readable description of
the reason.

The problem in poll.scm causes another failure while compiling
web/server/http.scm:

       GUILEC web/server/http.go
     Backtrace:
     In system/base/compile.scm:
      152: 19 [#<procedure 15d0b00 at system/base/compile.scm:150:8 (port)> #<closed: file 0>]
      201: 18 [read-and-compile #<input: web/server/http.scm 5> #:from ...]
      213: 17 [lp () #f #<module (#{ g60}#) 16324c8>]
      179: 16 [lp (#<procedure compile-tree-il (x e opts)>) (define-module # # ...) ...]
     In ice-9/boot-9.scm:
     2095: 15 [save-module-excursion #<procedure 194edb0 at language/scheme/compile-tree-il.scm:29:3 ()>]
     In language/scheme/compile-tree-il.scm:
       31: 14 [#<procedure 194edb0 at language/scheme/compile-tree-il.scm:29:3 ()>]
     In ./ice-9/psyntax.scm:
     1011: 13 [chi-top-sequence ((define-module # # # ...)) () ((top)) ...]
      898: 12 [scan ((define-module (web server http) #:use-module ...)) () ...]
      269: 11 [scan ((#(syntax-object let # ...) (#) (# #) ...)) () ...]
     In ice-9/eval.scm:
      374: 10 [eval # ()]
     In ice-9/boot-9.scm:
     2651: 9 [define-module* (web server http) #:filename ...]
     2626: 8 [resolve-imports ((# # #) (#) (#) (#) ...)]
     2564: 7 [resolve-interface (ice-9 poll) #:select ...]
     2489: 6 [#<procedure 14c98f0 at ice-9/boot-9.scm:2477:4 (name #:optional autoload version #:key ensure)> # ...]
     2756: 5 [try-module-autoload (ice-9 poll) #f]
     2095: 4 [save-module-excursion #<procedure 1b7f408 at ice-9/boot-9.scm:2757:17 ()>]
     2767: 3 [#<procedure 1b7f408 at ice-9/boot-9.scm:2757:17 ()>]
     In unknown file:
	?: 2 [primitive-load-path "ice-9/poll" #f]
	?: 1 [load-extension "libguile-2.0" "scm_init_poll"]
     In ice-9/boot-9.scm:
      119: 0 [#<procedure 15d0aa0 at ice-9/boot-9.scm:110:6 (thrown-k . args)> misc-error ...]

     ice-9/boot-9.scm:119:20: In procedure #<procedure 15d0aa0 at ice-9/boot-9.scm:110:6 (thrown-k . args)>:
     ice-9/boot-9.scm:119:20: In procedure %init-poll: `poll' unavailable on this platform
     make[2]: *** [web/server/http.go] Error 1

Other than that, the build finally succeeds!

P.S.  I found a couple of other possible places that don't support
Windows file names:

   ice-9/boot-9.scm:

     (define* (load-in-vicinity dir path #:optional reader)
       (define (canonical->suffix canon)
	 (cond
	  ((string-prefix? "/" canon) canon)
	  ((and (> (string-length canon) 2)
		(eqv? (string-ref canon 1) #\:))
	   ;; Paths like C:... transform to /C...
	   (string-append "/" (substring canon 0 1) (substring canon 2)))
	  (else canon)))


   system/base/compile.scm:

       (define (canonical->suffix canon)
	 (cond
	  ((string-prefix? "/" canon) canon)
	  ((and (> (string-length canon) 2)
		(eqv? (string-ref canon 1) #\:))
	   ;; Paths like C:... transform to /C...
	   (string-append "/" (substring canon 0 1) (substring canon 2)))
	  (else canon)))

I don't understand the "Paths like C:... transform to /C..." part.
Does that assume Cygwin?  Because the "transformed" file names will
not work in the native Windows build, which is what MinGW produces.

P.P.S.  I have still a few non-fatal warnings to investigate and
perhaps report, if they turn out to be real problems.  And then
there's a test suite.  Stay tuned.

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

[Eli Zaretskii]

> Date: Thu, 19 Jan 2012 19:35:04 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 10474@debbugs.gnu.org, commander.sirow@googlemail.com
> 
> > (The rest of your investigation is interesting!)
> 
> Here's some more ;-)

As promised, still more issues below.

1. Compilation warnings in deprecation.c:

       SNARF  deprecation.x
     deprecation.c:40:1: warning: "vsnprintf" redefined
     In file included from deprecation.c:25:
     ../lib/stdio.h:1605:1: warning: this is the location of the previous definition

This is because deprecation.c does this:

     /* Windows defines. */
     #ifdef __MINGW32__
     #define vsnprintf _vsnprintf
     #endif

but lib/stdio.h already did the same.  My solution was to add an
"#ifdef vsnprintf" condition to deprecation.c to avoid redefinition.

2. Compilation warning in expand.c:

       SNARF  expand.x
     expand.c:52:1: warning: "VOID" redefined
     In file included from d:/usr/include/windef.h:253,
		      from d:/usr/include/windows.h:48,
		      from d:/usr/include/winsock2.h:22,
		      from ../libguile/iselect.h:36,
		      from ../libguile/threads.h:30,
		      from ../libguile/gc.h:29,
		      from ../libguile/_scm.h:75,
		      from expand.c:27:
     d:/usr/include/winnt.h:75:1: warning: this is the location of the previous definition
     expand.c:54:1: warning: "CONST" redefined
     In file included from d:/usr/include/windows.h:48,
		      from d:/usr/include/winsock2.h:22,
		      from ../libguile/iselect.h:36,
		      from ../libguile/threads.h:30,
		      from ../libguile/gc.h:29,
		      from ../libguile/_scm.h:75,
		      from expand.c:27:
     d:/usr/include/windef.h:39:1: warning: this is the location of the previous definition

This is because expand.c does:

     #define VOID(src) \
       SCM_MAKE_EXPANDED_VOID(src)
     #define CONST(src, exp) \
       SCM_MAKE_EXPANDED_CONST(src, exp)

and Windows headers have their own definitions for VOID and CONST.

My solution was to add this to expand.c:

     #ifdef VOID
     #undef VOID
     #endif
     #ifdef CONST
     #undef CONST
     #endif

However, I really suggest that expand.c uses some less ubiquitous
symbol names, like SCM_CONST and SCM_VOID.

3. Compilation warning in filesys.c:

       SNARF  filesys.x
     filesys.c:119:1: warning: "mkdir" redefined
     In file included from ../lib/sys/stat.h:47,
		      from filesys.c:92:
     ../lib/sys/stat.h:808:1: warning: this is the location of the previous definition

This is because filesys.c does this:

     /* Some more definitions for the native Windows port. */
     #ifdef __MINGW32__
     # define mkdir(path, mode) mkdir (path)

But gnulib already redirected `mkdir' to its replacement function.  My
solution: don't define if already redirected.  To that end, I added
the following condition before the above #define:

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

I'm not sure using GNULIB_defined_rpl_mkdir is TRT here, but I didn't
find a better way.

4. Missing setenv needed by dynl.c:

       CC     dynl.lo
     dynl.c: In function `augment_env':
     dynl.c:141: warning: implicit declaration of function `setenv'

Solution: add a setenv implementation.  However, I think Guile would
be better off using a more portable putenv instead.

5. Compilation error in net_db.c:

       CC     net_db.lo
     net_db.c:460: error: `AI_ALL' undeclared here (not in a function)
     net_db.c:460: error: bit-field `_gl_verify_error_if_negative' width not an integer constant
     net_db.c:482: warning: "struct addrinfo" declared inside parameter list
     net_db.c:482: warning: its scope is only this definition or declaration, which is probably not what you want
     net_db.c: In function `scm_from_addrinfo':
     net_db.c:490: error: dereferencing pointer to incomplete type
     net_db.c:491: error: dereferencing pointer to incomplete type
     net_db.c:492: error: dereferencing pointer to incomplete type
     net_db.c:493: error: dereferencing pointer to incomplete type
     net_db.c:494: error: dereferencing pointer to incomplete type
     net_db.c:494: error: dereferencing pointer to incomplete type
     net_db.c:496: error: dereferencing pointer to incomplete type
     net_db.c:496: error: dereferencing pointer to incomplete type
     net_db.c: In function `scm_getaddrinfo':
     net_db.c:614: error: storage size of 'c_hints' isn't known
     net_db.c:657: warning: implicit declaration of function `getaddrinfo'
     net_db.c:665: error: dereferencing pointer to incomplete type
     net_db.c:665: warning: left-hand operand of comma expression has no effect
     net_db.c:668: warning: implicit declaration of function `freeaddrinfo'
     net_db.c:614: warning: unused variable `c_hints'
     net_db.c: At top level:
     net_db.c:680: error: `EAI_BADFLAGS' undeclared here (not in a function)
     net_db.c:680: error: bit-field `_gl_verify_error_if_negative' width not an integer constant
     net_db.c: In function `scm_gai_strerror':
     net_db.c:744: warning: implicit declaration of function `gai_strerror'
     net_db.c:744: warning: passing arg 1 of `scm_from_locale_string' makes pointer from integer without a cast
     In file included from net_db.c:755:
     ../libguile/net_db.x: In function `scm_init_net_db':
     ../libguile/net_db.x:17: error: `AI_PASSIVE' undeclared (first use in this function)
     ../libguile/net_db.x:17: error: (Each undeclared identifier is reported only once
     ../libguile/net_db.x:17: error: for each function it appears in.)
     ../libguile/net_db.x:18: error: `AI_CANONNAME' undeclared (first use in this function)
     ../libguile/net_db.x:19: error: `AI_NUMERICHOST' undeclared (first use in this function)
     ../libguile/net_db.x:20: error: `AI_NUMERICSERV' undeclared (first use in this function)
     ../libguile/net_db.x:21: error: `AI_V4MAPPED' undeclared (first use in this function)
     ../libguile/net_db.x:23: error: `AI_ADDRCONFIG' undeclared (first use in this function)
     ../libguile/net_db.x:27: error: `EAI_NONAME' undeclared (first use in this function)
     ../libguile/net_db.x:28: error: `EAI_AGAIN' undeclared (first use in this function)
     ../libguile/net_db.x:29: error: `EAI_FAIL' undeclared (first use in this function)
     ../libguile/net_db.x:30: error: `EAI_FAMILY' undeclared (first use in this function)
     ../libguile/net_db.x:31: error: `EAI_SOCKTYPE' undeclared (first use in this function)
     ../libguile/net_db.x:32: error: `EAI_SERVICE' undeclared (first use in this function)
     ../libguile/net_db.x:33: error: `EAI_MEMORY' undeclared (first use in this function)
     ../libguile/net_db.x:34: error: `EAI_SYSTEM' undeclared (first use in this function)
     ../libguile/net_db.x:35: error: `EAI_OVERFLOW' undeclared (first use in this function)
     net_db.c: In function `scm_getaddrinfo':
     net_db.c:663: warning: value computed is not used
     make[3]: *** [net_db.lo] Error 1

The reason is that this condition in net_db.c:

     #ifdef HAVE_WINSOCK2_H
     #include <winsock2.h>
     #else
     #include <sys/socket.h>
     #include <netdb.h>
     #include <netinet/in.h>
     #include <arpa/inet.h>
     #endif

is inappropriate when gnulib was used to wrap Windows socket
functions.  When gnulib _is_ used, the missing macros are already
defined by lib/sys/socket.h.  Therefore, I modified the condition to:

     #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>
     #include <netinet/in.h>
     #include <arpa/inet.h>
     #endif

using GNULIB_TEST_SOCKET as evidence that gnulib is being used.  I'm
not sure GNULIB_TEST_SOCKET is TRT, but I saw no better candidate.
Maybe gnulib should provide us with a better macro.

6. Compilation warnings in socket.c:

       CC     socket.lo
     socket.c: In function `scm_inet_ntop':
     socket.c:349: warning: implicit declaration of function `inet_ntop'
     socket.c:349: warning: assignment makes pointer from integer without a cast
     socket.c:357: warning: assignment makes pointer from integer without a cast
     socket.c: In function `scm_inet_pton':
     socket.c:397: warning: implicit declaration of function `inet_pton'

This is again because gnulib headers are not included although
available, due to exclusive test of HAVE_WINSOCK2_H.  Solution: change
this in socket.c:

     #ifdef HAVE_WINSOCK2_H

to say this:

     #if HAVE_WINSOCK2_H && !GNULIB_TEST_SOCKET

The same caveat about GNULIB_TEST_SOCKET applies here.

This completes the description of problems I needed to overcome for
building Guile with MinGW+MSYS.  You may notice that my report is
slightly different from Commander Sirow's report that started this bug
report, where we cover the same turf:

 . I didn't need to define a `struct timespec', probably because I
   don't have Pthreads-w32 installed, and so pthread.h did not get
   included in my build.

 . I solved the problems in net_db.c differently (see above), and I
   believe more correctly.

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

[Eli Zaretskii]

> Date: Sat, 21 Jan 2012 13:09:08 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 10474@debbugs.gnu.org, commander.sirow@googlemail.com
> 
> This completes the description of problems I needed to overcome for
> building Guile with MinGW+MSYS.

Well, it turns out there's more to tell:

1. First, I forgot to tell before that I needed to configure with

     CPPFLAGS='-D_WIN32_WINNT=0x0501' ./configure ...

because if I don't use CPPFLAGS='-D_WIN32_WINNT=0x0501, the configure
script claims various network-related functions, like getaddrinfo and
getnameinfo) are not available, which is a lie.

2. Warning messages from guile-snarf-docs:

     ./guile-snarf-docs -o memoize.doc memoize.c -- -DHAVE_CONFIG_H -DBUILDING_LIBGUILE=1 -I.. -I.. -I../lib -I../lib -Id:/usr/include   -D_WIN32_WINNT=0x0501 -I/d/usr/include -Id:/usr/include   -g -O2
     memoize.c:479:***Mismatching FUNC_NAME.  Should be: `#define FUNC_NAME s_"@prompt"'
     ./guile-snarf-docs -o pairs.doc pairs.c -- -DHAVE_CONFIG_H -DBUILDING_LIBGUILE=1 -I.. -I.. -I../lib -I../lib -Id:/usr/include   -D_WIN32_WINNT=0x0501 -I/d/usr/include -Id:/usr/include   -g -O2
     pairs.c:147:***Missing or erroneous `#define FUNC_NAME s_scm_cdr'
     pairs.c:150:***Missing or erroneous #undef for scm_car:
     pairs.c:155:***Missing or erroneous `#define FUNC_NAME s_scm_cddr'
     pairs.c:158:***Missing or erroneous #undef for scm_cdar:
     pairs.c:163:***Missing or erroneous `#define FUNC_NAME s_scm_cadr'
     pairs.c:166:***Missing or erroneous #undef for scm_caar:
     pairs.c:171:***Missing or erroneous `#define FUNC_NAME s_scm_cdddr'
     pairs.c:174:***Missing or erroneous #undef for scm_cddar:
     pairs.c:179:***Missing or erroneous `#define FUNC_NAME s_scm_cdadr'
     pairs.c:182:***Missing or erroneous #undef for scm_cdaar:
     pairs.c:187:***Missing or erroneous `#define FUNC_NAME s_scm_caddr'
     pairs.c:190:***Missing or erroneous #undef for scm_cadar:
     pairs.c:195:***Missing or erroneous `#define FUNC_NAME s_scm_caadr'
     pairs.c:198:***Missing or erroneous #undef for scm_caaar:
     pairs.c:203:***Missing or erroneous `#define FUNC_NAME s_scm_cddddr'
     pairs.c:206:***Missing or erroneous #undef for scm_cdddar:
     pairs.c:211:***Missing or erroneous `#define FUNC_NAME s_scm_cddadr'
     pairs.c:214:***Missing or erroneous #undef for scm_cddaar:
     pairs.c:219:***Missing or erroneous `#define FUNC_NAME s_scm_cdaddr'
     pairs.c:222:***Missing or erroneous #undef for scm_cdadar:
     pairs.c:227:***Missing or erroneous `#define FUNC_NAME s_scm_cdaadr'
     pairs.c:230:***Missing or erroneous #undef for scm_cdaaar:
     pairs.c:235:***Missing or erroneous `#define FUNC_NAME s_scm_cadddr'
     pairs.c:238:***Missing or erroneous #undef for scm_caddar:
     pairs.c:243:***Missing or erroneous `#define FUNC_NAME s_scm_cadadr'
     pairs.c:246:***Missing or erroneous #undef for scm_cadaar:
     pairs.c:251:***Missing or erroneous `#define FUNC_NAME s_scm_caaddr'
     pairs.c:254:***Missing or erroneous #undef for scm_caadar:
     pairs.c:259:***Missing or erroneous `#define FUNC_NAME s_scm_caaadr'
     pairs.c:262:***Missing or erroneous #undef for scm_caaaar:

These come from the guile-func-name-check Awk script, because the
offending functions indeed lack the usual "#define FUNC_NAME" and
"#undef FUNC_NAME" directives.

Are these problems real?  If not, I'd suggest to modify the Awk script
to not emit them: people might get alarmed without a good reason.

3. Error messages from makeinfo:

     rm -f guile-procedures.txt
     makeinfo --force -o guile-procedures.txt guile-procedures.texi || test -f guile-procedures.txt
     d:\usr\eli\utils\guile-2.0.3\libguile//guile-procedures.texi:10720: Cross reference to nonexistent node `Backslash Escapes' (perhaps incorrect sectioning?).
     d:\usr\eli\utils\guile-2.0.3\libguile//guile-procedures.texi:10415: Cross reference to nonexistent node `Network Address Conversion' (perhaps incorrect sectioning?).

and many more similar errors.

This is because guile-procedures.texi is not a complete Texinfo
source.  Since this command just generates a plain-text document, I
suggest to add --no-validate to makeinfo command-line switches.

4. Error in "make install-strip":

     make  install-data-hook
     make[5]: Entering directory `/d/usr/eli/utils/guile-2.0.3/meta'
     cd /d/usr/test/bin && rm -f guile-tools.exe && \
	     cp -p guild.exe guile-tools.exe
     cp: cannot stat `guild.exe': No such file or directory
     make[5]: *** [install-data-hook] Error 1

This happens because meta/Makefile.am has this:

     # What we now call `guild' used to be known as `guile-tools'.
     install-data-hook:
	     cd $(DESTDIR)$(bindir) && rm -f guile-tools$(EXEEXT) && \
	     $(LN_S) guild$(EXEEXT) guile-tools$(EXEEXT)

The $(EXEEXT) part should be removed.

5. Invoking the installed guile.exe aborts:

     D:\usr\test>guile
     Backtrace:
     In ice-9/boot-9.scm:
      162: 7 [catch #t #<catch-closure d47380> ...]
      170: 6 [#<procedure cf4a50 ()>]
     In unknown file:
	?: 5 [catch-closure]
     In ice-9/boot-9.scm:
       62: 4 [call-with-prompt prompt0 ...]
     In ice-9/top-repl.scm:
       33: 3 [#<procedure cf84f0 at ice-9/top-repl.scm:31:6 (thunk)> #<procedure cf8370 at ice-9/top-repl.scm:66:5 ()>]
       76: 2 [#<procedure cf8370 at ice-9/top-repl.scm:66:5 ()>]
     In system/repl/repl.scm:
      135: 1 [start-repl scheme #:debug #f]
     In system/repl/common.scm:
      139: 0 [make-repl scheme #f]

     system/repl/common.scm:139:25: In procedure make-repl:
     system/repl/common.scm:139:25: In procedure module-lookup: Unbound variable: times

This happens because HAVE_TIMES is not defined, as Windows doesn't
have `times' and the corresponding gnulib module was not imported to
Guile.

Like the problems with poll.scm, it sounds unwise to call at startup
procedures that depend on optional features which may not exist on the
underlying platform.  If guile.exe depends on some of these features,
it should fail to build if they don't exist.

I solved this by copy/pasting gnulib's times.c into stime.c.

6. I noticed that changes in C sources do not trigger recompilation of
   the *.scm files.  Should they?

7. guile.exe aborts again at startup:

     D:\usr\test>guile
     GNU Guile 2.0.3
     Copyright (C) 1995-2011 Free Software Foundation, Inc.

     Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'.
     This program is free software, and you are welcome to redistribute it
     under certain conditions; type `,show c' for details.

     Enter `,help' for help.
     While reading expression:
     ERROR: In procedure fport_input_waiting: Not fully implemented on this platform
     Backtrace:
     In ice-9/boot-9.scm:
      162: 10 [catch #t #<catch-closure d47370> ...]
      170: 9 [#<procedure cf4a50 ()>]
     In unknown file:
	?: 8 [catch-closure]
     In ice-9/boot-9.scm:
       62: 7 [call-with-prompt prompt0 ...]
     In ice-9/top-repl.scm:
       33: 6 [#<procedure cf8510 at ice-9/top-repl.scm:31:6 (thunk)> #<procedure cf8390 at ice-9/top-repl.scm:66:5 ()>]
       76: 5 [#<procedure cf8390 at ice-9/top-repl.scm:66:5 ()>]
     In system/repl/repl.scm:
      153: 4 [run-repl #]
      158: 3 [#<procedure f94660 ()>]
      125: 2 [#<procedure f9c5d0 at system/repl/repl.scm:118:4 (key . args)> misc-error ...]
      102: 1 [flush-all-input]
     In unknown file:
	?: 0 [char-ready? #<undefined>]

     ERROR: In procedure char-ready?:
     ERROR: In procedure fport_input_waiting: Not fully implemented on this platform

This is because Windows has neither `poll' nor `select' nor FIONREAD,
which are the 3 mechanisms supported by fport_input_waiting.

I solved it by adding this to fports.c:

     #elif defined (__MINGW32__)
       DWORD input_events;

       if (!GetNumberOfConsoleInputEvents (_get_osfhandle (fdes), &input_events))
	 scm_syserror ("fport_input_waiting");
       return (int) input_events;

and also the necessary definition of struct tms needed by stime.c.
But really the gnulib `select' module should be imported into Guile,
because the above will DTRT only for keyboard input ports.

This, finally, allows to start up guile.exe and type several simple
commands.

HTH

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

[Ludovic Courtès]

Hi Eli,

Thanks for doing all the hard work!

I’m willing to apply your changes, but could you send them in ‘git
format-patch’ format, with a log in GNU ChangeLog style, to make it
easier?

In prevision of the of an increased contribution rate ;-), could you
assign copyright to the FSF?  At first sight, these patches may be
applicable without copyright assignment, but that’s the limit, I think.

Eli Zaretskii <eliz@gnu.org> skribis:

> 1. Compilation warnings in deprecation.c:
>
>        SNARF  deprecation.x
>      deprecation.c:40:1: warning: "vsnprintf" redefined
>      In file included from deprecation.c:25:
>      ../lib/stdio.h:1605:1: warning: this is the location of the previous definition
>
> This is because deprecation.c does this:
>
>      /* Windows defines. */
>      #ifdef __MINGW32__
>      #define vsnprintf _vsnprintf
>      #endif
>
> but lib/stdio.h already did the same.  My solution was to add an
> "#ifdef vsnprintf" condition to deprecation.c to avoid redefinition.
>
> 2. Compilation warning in expand.c:
>
>        SNARF  expand.x
>      expand.c:52:1: warning: "VOID" redefined
>      In file included from d:/usr/include/windef.h:253,
> 		      from d:/usr/include/windows.h:48,
> 		      from d:/usr/include/winsock2.h:22,
> 		      from ../libguile/iselect.h:36,
> 		      from ../libguile/threads.h:30,
> 		      from ../libguile/gc.h:29,
> 		      from ../libguile/_scm.h:75,
> 		      from expand.c:27:
>      d:/usr/include/winnt.h:75:1: warning: this is the location of the previous definition
>      expand.c:54:1: warning: "CONST" redefined
>      In file included from d:/usr/include/windows.h:48,
> 		      from d:/usr/include/winsock2.h:22,
> 		      from ../libguile/iselect.h:36,
> 		      from ../libguile/threads.h:30,
> 		      from ../libguile/gc.h:29,
> 		      from ../libguile/_scm.h:75,
> 		      from expand.c:27:
>      d:/usr/include/windef.h:39:1: warning: this is the location of the previous definition
>
> This is because expand.c does:
>
>      #define VOID(src) \
>        SCM_MAKE_EXPANDED_VOID(src)
>      #define CONST(src, exp) \
>        SCM_MAKE_EXPANDED_CONST(src, exp)
>
> and Windows headers have their own definitions for VOID and CONST.
>
> My solution was to add this to expand.c:
>
>      #ifdef VOID
>      #undef VOID
>      #endif
>      #ifdef CONST
>      #undef CONST
>      #endif
>
> However, I really suggest that expand.c uses some less ubiquitous
> symbol names, like SCM_CONST and SCM_VOID.
>
> 3. Compilation warning in filesys.c:
>
>        SNARF  filesys.x
>      filesys.c:119:1: warning: "mkdir" redefined
>      In file included from ../lib/sys/stat.h:47,
> 		      from filesys.c:92:
>      ../lib/sys/stat.h:808:1: warning: this is the location of the previous definition
>
> This is because filesys.c does this:
>
>      /* Some more definitions for the native Windows port. */
>      #ifdef __MINGW32__
>      # define mkdir(path, mode) mkdir (path)
>
> But gnulib already redirected `mkdir' to its replacement function.  My
> solution: don't define if already redirected.  To that end, I added
> the following condition before the above #define:
>
>      /* 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
>
> I'm not sure using GNULIB_defined_rpl_mkdir is TRT here, but I didn't
> find a better way.

Strangely enough, the cross-build to MinGW32 at
<http://hydra.nixos.org/jobset/gnu/guile-2-0/> is not showing any of
these.  Any idea why?  That’s with MinGW 3.18.

> 4. Missing setenv needed by dynl.c:
>
>        CC     dynl.lo
>      dynl.c: In function `augment_env':
>      dynl.c:141: warning: implicit declaration of function `setenv'
>
> Solution: add a setenv implementation.  However, I think Guile would
> be better off using a more portable putenv instead.

I’ll try Gnulib’s setenv module.

> 5. Compilation error in net_db.c:

[...]

> is inappropriate when gnulib was used to wrap Windows socket
> functions.  When gnulib _is_ used, the missing macros are already
> defined by lib/sys/socket.h.  Therefore, I modified the condition to:
>
>      #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>
>      #include <netinet/in.h>
>      #include <arpa/inet.h>
>      #endif
>
> using GNULIB_TEST_SOCKET as evidence that gnulib is being used.  I'm
> not sure GNULIB_TEST_SOCKET is TRT, but I saw no better candidate.
> Maybe gnulib should provide us with a better macro.

This seems to be the right thing, according to gnulib-common.m4:

--8<---------------cut here---------------start------------->8---
# gl_MODULE_INDICATOR_FOR_TESTS([modulename])
# defines a C macro indicating the presence of the given module
# in lib or tests. This is useful to determine whether the module
# should be tested.
#                                             |  Value  |   Value   |
#                                             | in lib/ | in tests/ |
# --------------------------------------------+---------+-----------+
# Module present among main modules:          |    1    |     1     |
# --------------------------------------------+---------+-----------+
# Module present among tests-related modules: |    1    |     1     |
# --------------------------------------------+---------+-----------+
# Module not present at all:                  |    0    |     0     |
# --------------------------------------------+---------+-----------+
AC_DEFUN([gl_MODULE_INDICATOR_FOR_TESTS],
[
  AC_DEFINE([GNULIB_TEST_]m4_translit([[$1]],
      [abcdefghijklmnopqrstuvwxyz./-],
      [ABCDEFGHIJKLMNOPQRSTUVWXYZ___]), [1],
    [Define to 1 when the gnulib module $1 should be tested.])
])
--8<---------------cut here---------------end--------------->8---

Thanks!

Ludo’.

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

[Eli Zaretskii]

> From: ludo@gnu.org (Ludovic Courtès)
> Cc: 10474@debbugs.gnu.org,  commander.sirow@googlemail.com
> Date: Wed, 25 Jan 2012 22:12:04 +0100
> 
> Thanks for doing all the hard work!

Thanks for developing Guile.

> I’m willing to apply your changes, but could you send them in ‘git
> format-patch’ format, with a log in GNU ChangeLog style, to make it
> easier?

I can certainly add ChangeLog entries, but `git format-patch' would be
harder.  I don't have git installed on my development machine (git is
a bit of PITA on Windows).  What's wrong with "diff -u"?  I can divide
the diffs into separate chunks of related changes, so it will be
easier for you to produce separate commits, if that's what you want
from `git format-patch'.  If there's another reason for your request,
please tell what that is and I will try to make your job easier as
much as I can.  But installing git and cloning the Guile repo just to
submit these changes is something I'd like to avoid if possible.

> In prevision of the of an increased contribution rate ;-), could you
> assign copyright to the FSF?

Will do.

> Strangely enough, the cross-build to MinGW32 at
> <http://hydra.nixos.org/jobset/gnu/guile-2-0/> is not showing any of
> these.  Any idea why?  That’s with MinGW 3.18.

I have exactly zero experience with the cross-build MinGW
environment.  My MinGW installation is 3.14, FWIW.

> > is inappropriate when gnulib was used to wrap Windows socket
> > functions.  When gnulib _is_ used, the missing macros are already
> > defined by lib/sys/socket.h.  Therefore, I modified the condition to:
> >
> >      #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>
> >      #include <netinet/in.h>
> >      #include <arpa/inet.h>
> >      #endif
> >
> > using GNULIB_TEST_SOCKET as evidence that gnulib is being used.  I'm
> > not sure GNULIB_TEST_SOCKET is TRT, but I saw no better candidate.
> > Maybe gnulib should provide us with a better macro.
> 
> This seems to be the right thing, according to gnulib-common.m4:

OK.

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

[Ludovic Courtès]

Hi Eli,

Sorry for the late reply.

Eli Zaretskii <eliz@gnu.org> skribis:

> I can certainly add ChangeLog entries, but `git format-patch' would be
> harder.  I don't have git installed on my development machine (git is
> a bit of PITA on Windows).  What's wrong with "diff -u"?

It’s OK, but lacks commit meta-data (author, log, etc.), so it’s less
convenient to apply.  But that’s fine, if you prefer this way.

Thanks,
Ludo’.

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

[Eli Zaretskii]

> From: ludo@gnu.org (Ludovic Courtès)
> Cc: 10474@debbugs.gnu.org,  commander.sirow@googlemail.com
> Date: Sun, 29 Jan 2012 19:30:50 +0100
> 
> > I can certainly add ChangeLog entries, but `git format-patch' would be
> > harder.  I don't have git installed on my development machine (git is
> > a bit of PITA on Windows).  What's wrong with "diff -u"?
> 
> It’s OK, but lacks commit meta-data (author, log, etc.), so it’s less
> convenient to apply.

Is there a way to produce a text file with this information that you
could then submit to git instead of typing it by hand?  If so, I can
make such a file.

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

[Ludovic Courtès]

Eli Zaretskii <eliz@gnu.org> skribis:

>> From: ludo@gnu.org (Ludovic Courtès)
>> Cc: 10474@debbugs.gnu.org,  commander.sirow@googlemail.com
>> Date: Sun, 29 Jan 2012 19:30:50 +0100
>> 
>> > I can certainly add ChangeLog entries, but `git format-patch' would be
>> > harder.  I don't have git installed on my development machine (git is
>> > a bit of PITA on Windows).  What's wrong with "diff -u"?
>> 
>> It’s OK, but lacks commit meta-data (author, log, etc.), so it’s less
>> convenient to apply.
>
> Is there a way to produce a text file with this information that you
> could then submit to git instead of typing it by hand?

Don’t bother.  ;-)  Just send the diffs with ChangeLog entries, and
we’ll put it all together.

Thanks,
Ludo’.

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

[Andy Wingo]

Hi Eli,

Ludovic said it already, but it bears repeating: thank you very much for
this investigation!

I would like to take this task off his back, assuming he's OK with it:
the release process was terribly long, and Ludo deserves a rest ;)

I will assume that the canonicalize_file_name issues will get resolved
eventually in gnulib, once your assignment completes.  I will go
through the rest of the issues.

One thing: Ludo mentions that he had success with a cross-compiled MinGW
3.18 (IIRC?).  You were trying with 3.14.  Apparently there are 3.19 and
3.20 releases out.  Do you know if this is important?  I am ignorant
regarding MinGW, unfortunately.

I'll follow up on your other issues and patches.

Andy
-- 
http://wingolog.org/

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

[Eli Zaretskii]

> From: Andy Wingo <wingo@pobox.com>
> Cc: ludo@gnu.org (Ludovic Courtès),  10474@debbugs.gnu.org,
>  commander.sirow@googlemail.com
> Date: Thu, 02 Feb 2012 01:59:21 +0100
> 
> I would like to take this task off his back, assuming he's OK with it:
> the release process was terribly long, and Ludo deserves a rest ;)

Thank you.

> One thing: Ludo mentions that he had success with a cross-compiled MinGW
> 3.18 (IIRC?).  You were trying with 3.14.  Apparently there are 3.19 and
> 3.20 releases out.  Do you know if this is important?

I don't think it is.  I think the reason for the difference is that
Ludo used a cross-compiled environment, whereas I did it on
MS-Windows.

> I'll follow up on your other issues and patches.

I will try to send the patches with ChangeLog entries in a day or two.

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

[Ludovic Courtès]

Hi!

Andy Wingo <wingo@pobox.com> skribis:

> I would like to take this task off his back, assuming he's OK with it:
> the release process was terribly long, and Ludo deserves a rest ;)

Thank you.  :-)

> One thing: Ludo mentions that he had success with a cross-compiled MinGW
> 3.18 (IIRC?).

That’s on Hydra, and MinGW has since been upgraded to 3.20 there.  Note
that it’s a ‘--disable-networking’ build too, which is easier.

Thanks,
Ludo’.

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

[Eli Zaretskii]

> From: ludo@gnu.org (Ludovic Courtès)
> Cc: Eli Zaretskii <eliz@gnu.org>,  10474@debbugs.gnu.org,  commander.sirow@googlemail.com
> Date: Thu, 02 Feb 2012 17:39:44 +0100
> 
> Note that it’s a ‘--disable-networking’ build too, which is easier.

That might just explain at least some of the problems that I hit, but
Ludo didn't.  As you can see in my reports, quite a few of them were
related to network code in some way.

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

[Eli Zaretskii]

> From: Andy Wingo <wingo@pobox.com>
> Cc: ludo@gnu.org (Ludovic Courtès),  10474@debbugs.gnu.org,
>  commander.sirow@googlemail.com
> Date: Thu, 02 Feb 2012 01:59:21 +0100
> 
> I will assume that the canonicalize_file_name issues will get resolved
> eventually in gnulib, once your assignment completes.  I will go
> through the rest of the issues.

As promised, the diffs that I suggest to install to take care of the
problems I bumped into are at the end of this message.

For your convenience, I grouped the changes into several related
groups, in case you'd like to make them separate commits.  Each group
is preceded by a short description (a candidate for a commit log
message) and ChangeLog entries for the changes.

In addition to the diffs, there are a few other changes for which I
don't show my changes, because they were ad-hoc and not very clean.
Instead, I describe what I think should be the "right" solutions for
them:

 . lib/canonicalize-lgpl.c -- does not support Windows absolute file
                              names.  Will be fixed in gnulib.

 . libguile/dynl.c -- lacks setenv.  Gnulib's setenv should be used.

 . libguile/expand.c -- Defines CONST and VOID.  Should define
                        SCM_CONST and SCM_VOID (or some other, less
                        ubiquitous, symbols) instead.

 . libguile/fports.c -- Doesn't implement fport_input_waiting when
                        neither poll nor select nor FIONREAD are
                        available, without which interactive guile
                        won't start.  Should use the gnulib select
                        module.

 . libguile/socket.c -- Lacks implementation of `times' for
                        MS-Windows, without which guile.exe aborts
                        during startup.  Should use the gnulib times
                        module.

 . module/ice-9/boot-9.scm -- absolute-path? does not support Windows
                              file names with drive letters.  Windows
                              absolute file names match the regex
                              "\([a-zA-Z]:\)?[\\/]".  I don't know
                              Scheme well enough to write this in a
                              clean way, sorry...


Here are the diffs:


	Fix startup of guile.exe on MS-Windows.

	* module/system/base/compile.scm (call-with-output-file/atomic):
	Call close-port before deleting the temporary file name, otherwise
	deletion fails on MS-Windows (cannot delete a file that is still
	open).

	* libguile/load.c (scm_init_load_path) [__MINGW32__]: Convert
	backslashes to forward slashes in values of GUILE_LOAD_PATH and
	GUILE_LOAD_COMPILED_PATH.

--- module/system/base/compile.scm~0	2011-10-08 01:49:48.000000000 +0200
+++ module/system/base/compile.scm	2012-01-19 16:49:26.528084600 +0200
@@ -61,6 +61,7 @@
            (close-port tmp)
            (rename-file template filename))
          (lambda args
+	   (close-port tmp)
            (delete-file template)))))))
 
 (define (ensure-language x)


--- libguile/load.c~0	2011-10-08 01:49:48.000000000 +0200
+++ libguile/load.c	2012-01-17 16:47:19.325381400 +0200
@@ -310,10 +309,36 @@ scm_init_load_path ()
   }
 
   env = getenv ("GUILE_LOAD_PATH");
+#ifdef __MINGW32__
+  if (env)
+    {
+      char *p = env;
+
+      while (*p)
+	{
+	  if (*p == '\\')
+	    *p = '/';
+	  p++;
+	}
+    }
+#endif
   if (env)
     path = scm_parse_path (scm_from_locale_string (env), path);
 
   env = getenv ("GUILE_LOAD_COMPILED_PATH");
+#ifdef __MINGW32__
+  if (env)
+    {
+      char *p = env;
+
+      while (*p)
+	{
+	  if (*p == '\\')
+	    *p = '/';
+	  p++;
+	}
+    }
+#endif
   if (env)
     cpath = scm_parse_path (scm_from_locale_string (env), cpath);
 


	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/deprecation.c (vsnprintf) [__MINGW32__]: Don't redefine
	if already defined.  Avoids compiler warnings.

	* 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/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)
 	{

--- 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
 
--- 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__ */
 
+#ifndef O_BINARY
+# ifdef _O_BINARY
+#  define O_BINARY _O_BINARY
+# else
+#  define O_BINARY 0
+# endif
+#endif
+
 /* dirfd() returns the file descriptor underlying a "DIR*" directory stream.
    Found on MacOS X for instance.  The following definition is for Solaris
    10, it's probably not right elsewhere, but that's ok, it shouldn't be
 

	Read and write *.go files and copy files in binary mode on
	MS-Windows.

	* libguile/objcodes.c (O_BINARY): Define on all platforms.
	(make_objcode_from_file): Zero out errno before calling full_read,
	to make sure the value after the call reflects errors inside
	full_read.
	(scm_load_objcode): Open objcode files in binary mode, so that
	*.go files are read verbatim on MS-Windows.

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

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


--- libguile/objcodes.c~0	2011-10-08 01:49:48.000000000 +0200
+++ libguile/objcodes.c	2012-01-18 08:47:46.857202700 +0200
@@ -39,6 +39,14 @@
 #include "programs.h"
 #include "objcodes.h"
 
+#ifndef O_BINARY
+# ifdef _O_BINARY
+#  define O_BINARY _O_BINARY
+# else
+#  define O_BINARY 0
+# endif
+#endif
+
 /* SCM_OBJCODE_COOKIE, defined in _scm.h, is a magic value prepended
    to objcode on disk but not in memory.
 
@@ -169,9 +177,10 @@ make_objcode_from_file (int fd)
   {
     SCM bv = scm_c_make_bytevector (st.st_size - sizeof cookie);
 
+    errno = 0;
     if (full_read (fd, cookie, sizeof cookie) != sizeof cookie
-        || full_read (fd, SCM_BYTEVECTOR_CONTENTS (bv),
-                      SCM_BYTEVECTOR_LENGTH (bv)) != SCM_BYTEVECTOR_LENGTH (bv))
+	|| full_read (fd, SCM_BYTEVECTOR_CONTENTS (bv),
+		      SCM_BYTEVECTOR_LENGTH (bv)) != SCM_BYTEVECTOR_LENGTH (bv))
       {
         int errno_save = errno;
         (void) close (fd);
@@ -295,7 +304,7 @@ SCM_DEFINE (scm_load_objcode, "load-objc
   SCM_VALIDATE_STRING (1, file);
 
   c_file = scm_to_locale_string (file);
-  fd = open (c_file, O_RDONLY | O_CLOEXEC);
+  fd = open (c_file, O_RDONLY | O_BINARY | O_CLOEXEC);
   free (c_file);
   if (fd < 0) SCM_SYSERROR;
 

--- libguile/mkstemp.c~0	2010-12-08 11:07:02.000000000 +0200
+++ libguile/mkstemp.c	2012-01-18 08:46:36.123280400 +0200
@@ -43,6 +43,14 @@
 #include <process.h>
 #endif
 
+#ifndef O_BINARY
+# ifdef _O_BINARY
+#  define O_BINARY _O_BINARY
+# else
+#  define O_BINARY 0
+# endif
+#endif
+
 #ifndef TMP_MAX
 #define TMP_MAX 16384
 #endif
@@ -112,7 +120,7 @@ mkstemp (template)
       v /= 62;
       XXXXXX[5] = letters[v % 62];
 
-      fd = open (template, O_RDWR|O_CREAT|O_EXCL, 0600);
+      fd = open (template, O_RDWR|O_BINARY|O_CREAT|O_EXCL, 0600);
       if (fd >= 0)
 	/* The file does not exist.  */
 	return fd;


--- libguile/filesys.c~0	2011-10-08 01:49:48.000000000 +0200
+++ libguile/filesys.c	2012-01-18 08:29:49.629722000 +0200
@@ -1118,7 +1131,7 @@ SCM_DEFINE (scm_copy_file, "copy-file", 
   c_newfile = scm_to_locale_string (newfile);
   scm_dynwind_free (c_newfile);
 
-  oldfd = open_or_open64 (c_oldfile, O_RDONLY);
+  oldfd = open_or_open64 (c_oldfile, O_RDONLY | O_BINARY);
   if (oldfd == -1)
     SCM_SYSERROR;
 
@@ -1131,7 +1144,7 @@ SCM_DEFINE (scm_copy_file, "copy-file", 
     goto err_close_oldfd;
 
   /* use POSIX flags instead of 07777?.  */
-  newfd = open_or_open64 (c_newfile, O_WRONLY | O_CREAT | O_TRUNC,
+  newfd = open_or_open64 (c_newfile, O_WRONLY | O_BINARY | O_CREAT | O_TRUNC,
                           oldstat.st_mode & 07777);
   if (newfd == -1)
     {



	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>


--- libguile/socket.c~0	2011-10-08 01:49:48.000000000 +0200
+++ libguile/socket.c	2012-01-15 16:40:46.891296700 +0200
@@ -58,7 +58,7 @@
 #include <unistd.h>
 #endif
 #include <sys/types.h>
-#ifdef HAVE_WINSOCK2_H
+#if HAVE_WINSOCK2_H && !GNULIB_TEST_SOCKET
 #include <winsock2.h>
 #else
 #include <sys/socket.h>

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

[Andy Wingo]

Hi Eli,

I'm terribly sorry for the delay here.  I realize you've probably paged
out all of these patches from memory, but I would like to pick up the
loose ends.

On Thu 02 Feb 2012 18:34, Eli Zaretskii <eliz@gnu.org> writes:

>  . lib/canonicalize-lgpl.c -- does not support Windows absolute file
>                               names.  Will be fixed in gnulib.

I see you got this into gnulib in November
(http://lists.gnu.org/archive/html/bug-gnulib/2012-11/msg00090.html).
I just updated our Gnulib so we have it now.  Thanks!

>  . libguile/dynl.c -- lacks setenv.  Gnulib's setenv should be used.

This change was made in Guile on 25 January 2012.

>  . libguile/expand.c -- Defines CONST and VOID.  Should define
>                         SCM_CONST and SCM_VOID (or some other, less
>                         ubiquitous, symbols) instead.

Fixed in Guile on July 6 2012.

>  . libguile/fports.c -- Doesn't implement fport_input_waiting when
>                         neither poll nor select nor FIONREAD are
>                         available, without which interactive guile
>                         won't start.  Should use the gnulib select
>                         module.

Just added the module; thanks.

>  . libguile/socket.c -- Lacks implementation of `times' for
>                         MS-Windows, without which guile.exe aborts
>                         during startup.  Should use the gnulib times
>                         module.

Added; thanks.

I'll deal with the patches in a separate mail.

Cheers,

Andy
-- 
http://wingolog.org/

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

[Eli Zaretskii]

> From: Andy Wingo <wingo@pobox.com>
> Cc: ludo@gnu.org,  10474@debbugs.gnu.org,  commander.sirow@googlemail.com
> Date: Mon, 18 Feb 2013 19:10:41 +0100
> 
> I'm terribly sorry for the delay here.  I realize you've probably paged
> out all of these patches from memory, but I would like to pick up the
> loose ends.

Thanks.

> On Thu 02 Feb 2012 18:34, Eli Zaretskii <eliz@gnu.org> writes:
> 
> >  . lib/canonicalize-lgpl.c -- does not support Windows absolute file
> >                               names.  Will be fixed in gnulib.
> 
> I see you got this into gnulib in November
> (http://lists.gnu.org/archive/html/bug-gnulib/2012-11/msg00090.html).
> I just updated our Gnulib so we have it now.  Thanks!
> 
> >  . libguile/dynl.c -- lacks setenv.  Gnulib's setenv should be used.
> 
> This change was made in Guile on 25 January 2012.
> 
> >  . libguile/expand.c -- Defines CONST and VOID.  Should define
> >                         SCM_CONST and SCM_VOID (or some other, less
> >                         ubiquitous, symbols) instead.
> 
> Fixed in Guile on July 6 2012.
> 
> >  . libguile/fports.c -- Doesn't implement fport_input_waiting when
> >                         neither poll nor select nor FIONREAD are
> >                         available, without which interactive guile
> >                         won't start.  Should use the gnulib select
> >                         module.
> 
> Just added the module; thanks.
> 
> >  . libguile/socket.c -- Lacks implementation of `times' for
> >                         MS-Windows, without which guile.exe aborts
> >                         during startup.  Should use the gnulib times
> >                         module.
> 
> Added; thanks.

Thanks again.  Glad Guile is now more friendly to MinGW.

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

[Andy Wingo]

[-- Attachment #1: Type: text/plain, Size: 582 bytes --]

On Thu 02 Feb 2012 18:34, Eli Zaretskii <eliz@gnu.org> writes:

>  . module/ice-9/boot-9.scm -- absolute-path? does not support Windows
>                               file names with drive letters.  Windows
>                               absolute file names match the regex
>                               "\([a-zA-Z]:\)?[\\/]".  I don't know
>                               Scheme well enough to write this in a
>                               clean way, sorry...

Ludo, what do you think about the attached patch?  Eli, is it correct
and sufficient to fix path handling?

Andy


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-better-handling-of-windows-path-conventions.patch --]
[-- Type: text/x-diff, Size: 8000 bytes --]

From 965bda2befddb84101cfebb8a4a36f93ac3c248c Mon Sep 17 00:00:00 2001
From: Andy Wingo <wingo@pobox.com>
Date: Tue, 19 Feb 2013 11:41:44 +0100
Subject: [PATCH] better handling of windows path conventions

* libguile/filesys.c (scm_system_path_convention): New function.
  Exported to Scheme only.

* module/ice-9/boot-9.scm (path-separator?, absolute-path?): New
  predicates.
  (path-separator-string): New global variable.
  (in-vicinity): Use the new procedures.
  (load-user-init, try-module-autoload): Use path-separator-string.
  (load-in-vicinity): Update canonical->suffix.  A Racket-style
  `reroot-path' would be nice.

* module/ice-9/psyntax.scm (include): Use global `absolute-path?'.
---
 libguile/filesys.c       |   20 ++++++++++-
 module/ice-9/boot-9.scm  |   90 +++++++++++++++++++++++++++++++++++++++-------
 module/ice-9/psyntax.scm |    3 --
 3 files changed, 96 insertions(+), 17 deletions(-)

diff --git a/libguile/filesys.c b/libguile/filesys.c
index 9c39307..d48a655 100644
--- a/libguile/filesys.c
+++ b/libguile/filesys.c
@@ -1,5 +1,5 @@
 /* Copyright (C) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2004, 2006,
- *   2009, 2010, 2011, 2012 Free Software Foundation, Inc.
+ *   2009, 2010, 2011, 2012, 2013 Free Software Foundation, Inc.
  *
  * This library is free software; you can redistribute it and/or
  * modify it under the terms of the GNU Lesser General Public License
@@ -1434,6 +1434,24 @@ SCM_DEFINE (scm_mkstemp, "mkstemp!", 1, 0, 0,
 
 SCM scm_dot_string;
 
+#ifdef __MINGW32__
+SCM_SYMBOL (sym_path_convention, "windows");
+#else
+SCM_SYMBOL (sym_path_convention, "posix");
+#endif
+
+SCM_INTERNAL SCM scm_system_path_convention (void);
+
+SCM_DEFINE (scm_system_path_convention, "system-path-convention", 0, 0, 0,
+            (void),
+	    "Return either @code{posix} or @code{windows}, depending on\n"
+            "what kind of system this Guile is running on.")
+#define FUNC_NAME s_scm_system_path_convention
+{
+  return sym_path_convention;
+}
+#undef FUNC_NAME
+
 SCM_DEFINE (scm_dirname, "dirname", 1, 0, 0, 
             (SCM filename),
 	    "Return the directory name component of the file name\n"
diff --git a/module/ice-9/boot-9.scm b/module/ice-9/boot-9.scm
index 31d4523..18178b5 100644
--- a/module/ice-9/boot-9.scm
+++ b/module/ice-9/boot-9.scm
@@ -296,6 +296,12 @@ If there is no handler at all, Guile prints an error and then exits."
              (apply f (car l1) (map car rest))
              (lp (cdr l1) (map cdr rest))))))))
 
+;; Temporary definition used in the include-from-path expansion;
+;; replaced later.
+
+(define (absolute-path? path)
+  #t)
+
 ;;; {and-map and or-map}
 ;;;
 ;;; (and-map fn lst) is like (and (fn (car lst)) (fn (cadr lst)) (fn...) ...)
@@ -1411,16 +1417,70 @@ VALUE."
 ;;; {Load Paths}
 ;;;
 
+(let-syntax ((compile-time-case
+              (lambda (stx)
+                (syntax-case stx ()
+                  ((_ exp clauses ...)
+                   (let ((val (primitive-eval (syntax->datum #'exp))))
+                     (let next-clause ((clauses #'(clauses ...)))
+                       (syntax-case clauses (else)
+                         (()
+                          (syntax-violation 'compile-time-case
+                                            "all clauses failed to match" stx))
+                         (((else form ...))
+                          #'(begin form ...))
+                         ((((k ...) form ...) clauses ...)
+                          (if (memv val (syntax->datum #'(k ...)))
+                              #'(begin form ...)
+                              (next-clause #'(clauses ...))))))))))))
+  ;; emacs: (put 'compile-time-case 'scheme-indent-function 1)
+  (compile-time-case (system-path-convention)
+    ((posix)
+     (define (path-separator? c)
+       (char=? c #\/))
+
+     (define path-separator-string "/")
+
+     (define (absolute-path? path)
+       (string-prefix? "/" path)))
+
+    ((windows)
+     (define (path-separator? c)
+       (or (char=? c #\/)
+           (char=? c #\\)))
+
+     (define path-separator-string "\\")
+
+     (define (absolute-path? path)
+       (define (unc-path?)
+         ;; Universal Naming Convention (UNC) paths start with \\, and
+         ;; are always absolute.
+         (string-prefix? "\\\\" path))
+       (define (has-drive-specifier?)
+         (and (>= (string-length path) 2)
+              (let ((drive (string-ref path 0)))
+                (or (char<=? #\a drive #\z)
+                    (char<=? #\A drive #\Z)))
+              (eqv? (string-ref path 1) #\:)))
+       (define (path-separator-at-index? idx)
+         (and (> (string-length path) idx)
+              (case (string-ref path idx)
+                ((#\\ #\/) #t)
+                (else #f))))
+       (or (unc-path?)
+           (if (has-drive-specifier?)
+               (path-separator-at-index? 2)
+               (path-separator-at-index? 0)))))))
+
 (define (in-vicinity vicinity file)
   (let ((tail (let ((len (string-length vicinity)))
                 (if (zero? len)
                     #f
                     (string-ref vicinity (- len 1))))))
     (string-append vicinity
-                   (if (or (not tail)
-                           (eq? tail #\/))
+                   (if (or (not tail) (path-separator? tail))
                        ""
-                       "/")
+                       path-separator-string)
                    file)))
 
 \f
@@ -1440,7 +1500,7 @@ VALUE."
 (define (load-user-init)
   (let* ((home (or (getenv "HOME")
                    (false-if-exception (passwd:dir (getpwuid (getuid))))
-                   "/"))  ;; fallback for cygwin etc.
+                   path-separator-string))  ;; fallback for cygwin etc.
          (init-file (in-vicinity home ".guile")))
     (if (file-exists? init-file)
         (primitive-load init-file))))
@@ -2777,7 +2837,8 @@ but it fails to load."
          (dir-hint-module-name (reverse (cdr reverse-name)))
          (dir-hint (apply string-append
                           (map (lambda (elt)
-                                 (string-append (symbol->string elt) "/"))
+                                 (string-append (symbol->string elt)
+                                                path-separator-string))
                                dir-hint-module-name))))
     (resolve-module dir-hint-module-name #f)
     (and (not (autoload-done-or-in-progress? dir-hint name))
@@ -3635,11 +3696,17 @@ reading PATH with READER."
 
   (define (canonical->suffix canon)
     (cond
-     ((string-prefix? "/" canon) canon)
-     ((and (> (string-length canon) 2)
-           (eqv? (string-ref canon 1) #\:))
-      ;; Paths like C:... transform to /C...
-      (string-append "/" (substring canon 0 1) (substring canon 2)))
+     ((and (not (string-null? canon))
+           (path-separator? (string-ref canon 0)))
+      canon)
+     ((and (eq? (system-path-convention) 'windows)
+           (absolute-path? canon))
+      ;; An absolute path that doesn't start with a path separator starts with a
+      ;; drive component.  Transform the drive component to a path element:
+      ;; c:\foo -> \c\foo.
+      (string-append path-separator-string
+                     (substring canon 0 1)
+                     (substring canon 2)))
      (else canon)))
 
   (define compiled-extension
@@ -3723,9 +3790,6 @@ reading PATH with READER."
         (warn-about-exception k args)
         #f)))
 
-  (define (absolute-path? path)
-    (string-prefix? "/" path))
-
   (define (sans-extension file)
     (let ((dot (string-rindex file #\.)))
       (if dot
diff --git a/module/ice-9/psyntax.scm b/module/ice-9/psyntax.scm
index 565c911..2e71aab 100644
--- a/module/ice-9/psyntax.scm
+++ b/module/ice-9/psyntax.scm
@@ -2929,9 +2929,6 @@
 
 (define-syntax include
   (lambda (x)
-    (define (absolute-path? path)
-      (string-prefix? "/" path))
-
     (define read-file
       (lambda (fn dir k)
         (let ((p (open-input-file
-- 
1.7.10.4


[-- Attachment #3: Type: text/plain, Size: 26 bytes --]


-- 
http://wingolog.org/

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

[Ludovic Courtès]

Andy Wingo <wingo@pobox.com> skribis:

> +(let-syntax ((compile-time-case
> +              (lambda (stx)
> +                (syntax-case stx ()
> +                  ((_ exp clauses ...)
> +                   (let ((val (primitive-eval (syntax->datum #'exp))))
> +                     (let next-clause ((clauses #'(clauses ...)))
> +                       (syntax-case clauses (else)
> +                         (()
> +                          (syntax-violation 'compile-time-case
> +                                            "all clauses failed to match" stx))
> +                         (((else form ...))
> +                          #'(begin form ...))
> +                         ((((k ...) form ...) clauses ...)
> +                          (if (memv val (syntax->datum #'(k ...)))
> +                              #'(begin form ...)
> +                              (next-clause #'(clauses ...))))))))))))
> +  ;; emacs: (put 'compile-time-case 'scheme-indent-function 1)
> +  (compile-time-case (system-path-convention)
> +    ((posix)
> +     (define (path-separator? c)
> +       (char=? c #\/))
> +
> +     (define path-separator-string "/")
> +
> +     (define (absolute-path? path)
> +       (string-prefix? "/" path)))

I think we must stick to GNU conventions–i.e., write “file name” when
speaking of the name of a file, as above, and “path” when speaking of a
search path.

This is important here because sooner or later someone will ask about
“path separators” (semicolon vs. colon), not to be confused with file
name or directory separators.

WDYT?

(Yes, there are counter-examples in Guile code, but that’s no excuse. ;-))

> +    ((windows)
> +     (define (path-separator? c)
> +       (or (char=? c #\/)
> +           (char=? c #\\)))
> +
> +     (define path-separator-string "\\")
> +
> +     (define (absolute-path? path)
> +       (define (unc-path?)
> +         ;; Universal Naming Convention (UNC) paths start with \\, and
> +         ;; are always absolute.
> +         (string-prefix? "\\\\" path))

What about adding here a link to a page that describes “UNC”?

Otherwise, looks good to me, and it’s great that progress is made on
that front!

Ludo’.

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

[Andy Wingo]

Hi,

On Tue 19 Feb 2013 13:55, ludo@gnu.org (Ludovic Courtès) writes:

> Andy Wingo <wingo@pobox.com> skribis:
>
>> +  (compile-time-case (system-path-convention)
>> +    ((posix)
>> +     (define (path-separator? c)
>> +       (char=? c #\/))
>> +
>> +     (define path-separator-string "/")
>> +
>> +     (define (absolute-path? path)
>> +       (string-prefix? "/" path)))
>
> I think we must stick to GNU conventions–i.e., write “file name” when
> speaking of the name of a file, as above, and “path” when speaking of a
> search path.
>
> This is important here because sooner or later someone will ask about
> “path separators” (semicolon vs. colon), not to be confused with file
> name or directory separators.
>
> WDYT?

I'm fine with this.  I'll go for these names, and let someone else fix
it up if they care enough:

  system-file-name-convention
  file-name-separator?
  file-name-separator-string
  absolute-file-name?

> What about adding here a link to a page that describes “UNC”?

http://msdn.microsoft.com/en-us/library/windows/desktop/aa365247(v=vs.85).aspx#fully_qualified_vs._relative_paths
is the link; will include it.

Thanks,

Andy
-- 
http://wingolog.org/

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

[Andy Wingo]

Hi Eli,

On Thu 02 Feb 2012 18:34, Eli Zaretskii <eliz@gnu.org> writes:

>  . module/ice-9/boot-9.scm -- absolute-path? does not support Windows
>                               file names with drive letters.  Windows
>                               absolute file names match the regex
>                               "\([a-zA-Z]:\)?[\\/]".  I don't know
>                               Scheme well enough to write this in a
>                               clean way, sorry...

I pushed a fix that recognizes drive components and UNC file names as
absolute, and that attempts to allow for (and prefer) backslash as a
file name separator on Windows systems.

> 	Fix startup of guile.exe on MS-Windows.
>
> 	* module/system/base/compile.scm (call-with-output-file/atomic):
> 	Call close-port before deleting the temporary file name, otherwise
> 	deletion fails on MS-Windows (cannot delete a file that is still
> 	open).

Applied, thanks.

> 	* libguile/load.c (scm_init_load_path) [__MINGW32__]: Convert
> 	backslashes to forward slashes in values of GUILE_LOAD_PATH and
> 	GUILE_LOAD_COMPILED_PATH.

Is this necessary now that backslash is recognized as a file name
separator?  I did not apply this part yet.

Still working on the rest.

Thanks,

Andy
-- 
http://wingolog.org/

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

[Eli Zaretskii]

> From: Andy Wingo <wingo@pobox.com>
> Cc: ludo@gnu.org,  10474@debbugs.gnu.org
> Date: Tue, 19 Feb 2013 11:44:35 +0100
> 
> >  . module/ice-9/boot-9.scm -- absolute-path? does not support Windows
> >                               file names with drive letters.  Windows
> >                               absolute file names match the regex
> >                               "\([a-zA-Z]:\)?[\\/]".  I don't know
> >                               Scheme well enough to write this in a
> >                               clean way, sorry...
> 
> Ludo, what do you think about the attached patch?  Eli, is it correct
> and sufficient to fix path handling?

Yes, I think so.  I have a couple of comments, though:

> +       (define (unc-path?)
> +         ;; Universal Naming Convention (UNC) paths start with \\, and
> +         ;; are always absolute.
> +         (string-prefix? "\\\\" path))

A UNC file name can also begin with 2 slashes, as in "//foo/bar/".  In
general, Windows system calls treat both kinds of slashes identically.

>    (define (canonical->suffix canon)
>      (cond
> -     ((string-prefix? "/" canon) canon)
> -     ((and (> (string-length canon) 2)
> -           (eqv? (string-ref canon 1) #\:))
> -      ;; Paths like C:... transform to /C...
> -      (string-append "/" (substring canon 0 1) (substring canon 2)))
> +     ((and (not (string-null? canon))
> +           (path-separator? (string-ref canon 0)))
> +      canon)
> +     ((and (eq? (system-path-convention) 'windows)
> +           (absolute-path? canon))
> +      ;; An absolute path that doesn't start with a path separator starts with a
> +      ;; drive component.  Transform the drive component to a path element:
> +      ;; c:\foo -> \c\foo.

Why is this transformation needed?  Native Windows system calls will
not understand "/c/foo" syntax.  What is this about?  (I know it was
in the original code, but I didn't understand it then, either.)

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

[Eli Zaretskii]

> From: Andy Wingo <wingo@pobox.com>
> Cc: ludo@gnu.org,  10474@debbugs.gnu.org,
> Date: Tue, 19 Feb 2013 16:47:02 +0100
> 
> Hi Eli,
> 
> On Thu 02 Feb 2012 18:34, Eli Zaretskii <eliz@gnu.org> writes:
> 
> >  . module/ice-9/boot-9.scm -- absolute-path? does not support Windows
> >                               file names with drive letters.  Windows
> >                               absolute file names match the regex
> >                               "\([a-zA-Z]:\)?[\\/]".  I don't know
> >                               Scheme well enough to write this in a
> >                               clean way, sorry...
> 
> I pushed a fix that recognizes drive components and UNC file names as
> absolute, and that attempts to allow for (and prefer) backslash as a
> file name separator on Windows systems.

Thanks.

> > 	* libguile/load.c (scm_init_load_path) [__MINGW32__]: Convert
> > 	backslashes to forward slashes in values of GUILE_LOAD_PATH and
> > 	GUILE_LOAD_COMPILED_PATH.
> 
> Is this necessary now that backslash is recognized as a file name
> separator?

Possibly.  But are you sure there's no more references to '/' alone in
C code (as opposed to in Scheme)?

> Still working on the rest.

Thanks.

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

[Andy Wingo]

Hi Eli,

Sorry for the large number of mails.

You sent this patch:

On Thu 02 Feb 2012 18:34, 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?

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

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

[Andy Wingo]

Hi,

On Tue 19 Feb 2013 18:53, Eli Zaretskii <eliz@gnu.org> writes:

>> +       (define (unc-path?)
>> +         ;; Universal Naming Convention (UNC) paths start with \\, and
>> +         ;; are always absolute.
>> +         (string-prefix? "\\\\" path))
>
> A UNC file name can also begin with 2 slashes, as in "//foo/bar/".  In
> general, Windows system calls treat both kinds of slashes identically.

Interesting, thanks.

>>    (define (canonical->suffix canon)
>>      (cond
>> -     ((string-prefix? "/" canon) canon)
>> -     ((and (> (string-length canon) 2)
>> -           (eqv? (string-ref canon 1) #\:))
>> -      ;; Paths like C:... transform to /C...
>> -      (string-append "/" (substring canon 0 1) (substring canon 2)))
>> +     ((and (not (string-null? canon))
>> +           (path-separator? (string-ref canon 0)))
>> +      canon)
>> +     ((and (eq? (system-path-convention) 'windows)
>> +           (absolute-path? canon))
>> +      ;; An absolute path that doesn't start with a path separator starts with a
>> +      ;; drive component.  Transform the drive component to a path element:
>> +      ;; c:\foo -> \c\foo.
>
> Why is this transformation needed?  Native Windows system calls will
> not understand "/c/foo" syntax.  What is this about?  (I know it was
> in the original code, but I didn't understand it then, either.)

Auto-compiling /foo/bar/baz.scm produces
$HOME/.cache/guile/2.0/ccache/foo/bar/baz.go.  This turns the drive
component into a path element on Windows so compiling C:/foo.scm caches
$HOME/.cache/guile/2.0/ccache/c/foo.go.

Andy
-- 
http://wingolog.org/

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

[Eli Zaretskii]

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

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

[Eli Zaretskii]

> From: Andy Wingo <wingo@pobox.com>
> Cc: ludo@gnu.org,  10474@debbugs.gnu.org
> Date: Tue, 19 Feb 2013 22:44:39 +0100
> 
> >>    (define (canonical->suffix canon)
> >>      (cond
> >> -     ((string-prefix? "/" canon) canon)
> >> -     ((and (> (string-length canon) 2)
> >> -           (eqv? (string-ref canon 1) #\:))
> >> -      ;; Paths like C:... transform to /C...
> >> -      (string-append "/" (substring canon 0 1) (substring canon 2)))
> >> +     ((and (not (string-null? canon))
> >> +           (path-separator? (string-ref canon 0)))
> >> +      canon)
> >> +     ((and (eq? (system-path-convention) 'windows)
> >> +           (absolute-path? canon))
> >> +      ;; An absolute path that doesn't start with a path separator starts with a
> >> +      ;; drive component.  Transform the drive component to a path element:
> >> +      ;; c:\foo -> \c\foo.
> >
> > Why is this transformation needed?  Native Windows system calls will
> > not understand "/c/foo" syntax.  What is this about?  (I know it was
> > in the original code, but I didn't understand it then, either.)
> 
> Auto-compiling /foo/bar/baz.scm produces
> $HOME/.cache/guile/2.0/ccache/foo/bar/baz.go.  This turns the drive
> component into a path element on Windows so compiling C:/foo.scm caches
> $HOME/.cache/guile/2.0/ccache/c/foo.go.

Thanks, I see the light now.  Perhaps consider adding a comment there
pointing to this use of the transformation.

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

[Andy Wingo]

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/

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

[Eli Zaretskii]

> From: Andy Wingo <wingo@pobox.com>
> Cc: ludo@gnu.org,  10474@debbugs.gnu.org
> Date: Wed, 20 Feb 2013 22:57:18 +0100
> 
> >> > --- 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?

Maybe it's some obscure bug my compiler.  If you can get away without
a warning in such situations, even when the prototype does specify
"const char **", then feel free to disregard these changes.  They are
certainly not Windows or MinGW specific.

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

[Andy Wingo]

On Thu 21 Feb 2013 04:49, Eli Zaretskii <eliz@gnu.org> writes:

>> >   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?
>
> Maybe it's some obscure bug my compiler.  If you can get away without
> a warning in such situations, even when the prototype does specify
> "const char **", then feel free to disregard these changes.  They are
> certainly not Windows or MinGW specific.

I'm not trying to disregard your change, but the cast really shouldn't
be necessary.  Adding an explicit cast to (const char**) would start
causing warnings on platforms that have a posix iconv prototype, like
those with GNU libc.

So, very respectfully, I think I will not apply this one.

Andy
-- 
http://wingolog.org/

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

[Andy Wingo]

On Tue 19 Feb 2013 18:53, Eli Zaretskii <eliz@gnu.org> writes:

>> +       (define (unc-path?)
>> +         ;; Universal Naming Convention (UNC) paths start with \\, and
>> +         ;; are always absolute.
>> +         (string-prefix? "\\\\" path))
>
> A UNC file name can also begin with 2 slashes, as in "//foo/bar/".  In
> general, Windows system calls treat both kinds of slashes identically.

I've fixed this, I think.

Thanks for the note,

Andy
-- 
http://wingolog.org/

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

[Andy Wingo]

On Tue 19 Feb 2013 19:00, Eli Zaretskii <eliz@gnu.org> writes:

>> > 	* libguile/load.c (scm_init_load_path) [__MINGW32__]: Convert
>> > 	backslashes to forward slashes in values of GUILE_LOAD_PATH and
>> > 	GUILE_LOAD_COMPILED_PATH.
>> 
>> Is this necessary now that backslash is recognized as a file name
>> separator?
>
> Possibly.  But are you sure there's no more references to '/' alone in
> C code (as opposed to in Scheme)?

I am pretty sure, yes.  I just pushed some patches to make sure this is
the case, altering load.c's logic to be more structurally similar to
boot-9.scm's and preferring backslashes on Windows.

So with these last commits, hopefully native MinGW builds are supported.
Would you mind testing again?  Please send a new mail to
bug-guile@gnu.org to track any new failures.

Thanks,

Andy
-- 
http://wingolog.org/

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

[Eli Zaretskii]

> From: Andy Wingo <wingo@pobox.com>
> Cc: ludo@gnu.org,  10474-done@debbugs.gnu.org
> Date: Sun, 24 Feb 2013 14:25:06 +0100
> 
> So with these last commits, hopefully native MinGW builds are supported.
> Would you mind testing again?

Thanks, will do when I have time.

bug#14361: Building guile 2.0.9 under mingw + msys

[Eli Zaretskii]

> From: Andy Wingo <wingo@pobox.com>
> Cc: ludo@gnu.org,  10474-done@debbugs.gnu.org
> Date: Sun, 24 Feb 2013 14:25:06 +0100
> 
> So with these last commits, hopefully native MinGW builds are supported.
> Would you mind testing again?  Please send a new mail to
> bug-guile@gnu.org to track any new failures.

Thanks, and sorry for a long delay.

I tried today building Guile 2.0.9.  The C compilation went very
smoothly, with only a couple of warnings (one is the known iconv
prototype "issue", the other a variable that is set and not used).
However, once it got to compiling Scheme files, it repeatedly failed
after writing each .go file.  Here are a few typical failures:

       GEN      guile-procedures.texi
     Backtrace:
     In unknown file:
	?: 3 [apply-smob/1 #<boot-closure 234da60 (_ _ _)> #t ...]
	?: 2 [apply-smob/1 #<catch-closure 2e07050> quit #<unspecified>]
	?: 1 [apply-smob/1 #<boot-closure 234da60 (_ _ _)> #t ...]
	?: 0 [apply-smob/1 #<catch-closure 3f7eea0>]

     ERROR:

The program then sits at the ERROR: prompt, but does not accept any
input.

Seems that this comes from smob.c:

     static SCM
     scm_smob_trampoline (unsigned int nreq, unsigned int nopt,
			  unsigned int rest)
     {
       SCM trampoline;

       if (SCM_UNLIKELY (rest > 1 || nreq + nopt + rest > 3))
	 scm_out_of_range ("make-smob", scm_from_uint (nreq + nopt + rest));

       trampoline = SCM_SMOB_TRAMPOLINE (nreq, nopt, rest);

       if (SCM_LIKELY (SCM_UNPACK (trampoline)))
	 return trampoline;

       switch (nreq + nopt + rest)
	 {
	   /* The + 1 is for the smob itself.  */
	 case 0:
	   trampoline = scm_c_make_gsubr ("apply-smob/0", nreq + 1, nopt, rest,
					  apply_0);
	   break;
	 case 1:
	   trampoline = scm_c_make_gsubr ("apply-smob/1", nreq + 1, nopt, rest,
					  apply_1);

But I have no idea what it means.

When this happens, guile.exe still runs (actually, there are 2 Guile
processes, one a child of the other), so it is impossible to delete
guile-procedures.texi, because one of these processes holds it open.
I needed to kill guile.exe (the child) to be able to try again.

I tried "make -k" to see how far I can advance.  The next compilation
of ice-9/eval.scm then stops with the same error:

     make[2]: Entering directory `/d/usr/eli/utils/guile-2.0.9/module'
       GUILEC ice-9/eval.go
     wrote `ice-9/eval.go'
     Backtrace:
     In unknown file:
	?: 3 [apply-smob/1 #<boot-closure 26cca60 (_ _ _)> #t ...]
	?: 2 [apply-smob/1 #<catch-closure 2b12100> quit #<unspecified>]
	?: 1 [apply-smob/1 #<boot-closure 26cca60 (_ _ _)> #t ...]
	?: 0 [apply-smob/1 #<catch-closure 3af6340>]

     ERROR:

Similarly after compiling ice-9/readline.scm:

     wrote `ice-9/readline.go'
     Backtrace:
     In unknown file:
	?: 4 [apply-smob/1 #<catch-closure 246faf0> quit #<unspecified>]
     In ice-9/eval.scm:
      484: 3 [eval # #]
      481: 2 [lp (#<fluid 13>) (#<procedure 40d9d20 at ice-9/eval.scm:264:7 %args>)]
     In unknown file:
	?: 1 [apply-smob/1 #<catch-closure 3ccb440>]
     In ice-9/eval.scm:
      481: 0 [lp (#<fluid 12>) ((#<catch-closure 3ccb420>))]

     ice-9/eval.scm:481:19:

Any ideas?  Where should I look for the source of this problem?

TIA

bug#14361: Building guile 2.0.9 under mingw + msys

[Andy Wingo]

Hi Eli :)

Thank you for your ongoing work on MinGW and Guile, it's really
appreciated.  I just wanted to say that explicitly here, even though I'm
closing this bug, as I understand that things have progressed a bit in
these 3 years; anyway.  Your work is so valuable to many users.  Thanks!

Andy

On Tue 07 May 2013 19:18, Eli Zaretskii <eliz@gnu.org> writes:

>> From: Andy Wingo <wingo@pobox.com>
>> Cc: ludo@gnu.org,  10474-done@debbugs.gnu.org
>> Date: Sun, 24 Feb 2013 14:25:06 +0100
>> 
>> So with these last commits, hopefully native MinGW builds are supported.
>> Would you mind testing again?  Please send a new mail to
>> bug-guile@gnu.org to track any new failures.
>
> Thanks, and sorry for a long delay.
>
> I tried today building Guile 2.0.9.  The C compilation went very
> smoothly, with only a couple of warnings (one is the known iconv
> prototype "issue", the other a variable that is set and not used).
> However, once it got to compiling Scheme files, it repeatedly failed
> after writing each .go file.  Here are a few typical failures:
>
>        GEN      guile-procedures.texi
>      Backtrace:
>      In unknown file:
> 	?: 3 [apply-smob/1 #<boot-closure 234da60 (_ _ _)> #t ...]
> 	?: 2 [apply-smob/1 #<catch-closure 2e07050> quit #<unspecified>]
> 	?: 1 [apply-smob/1 #<boot-closure 234da60 (_ _ _)> #t ...]
> 	?: 0 [apply-smob/1 #<catch-closure 3f7eea0>]
>
>      ERROR:
>
> The program then sits at the ERROR: prompt, but does not accept any
> input.
>
> Seems that this comes from smob.c:
>
>      static SCM
>      scm_smob_trampoline (unsigned int nreq, unsigned int nopt,
> 			  unsigned int rest)
>      {
>        SCM trampoline;
>
>        if (SCM_UNLIKELY (rest > 1 || nreq + nopt + rest > 3))
> 	 scm_out_of_range ("make-smob", scm_from_uint (nreq + nopt + rest));
>
>        trampoline = SCM_SMOB_TRAMPOLINE (nreq, nopt, rest);
>
>        if (SCM_LIKELY (SCM_UNPACK (trampoline)))
> 	 return trampoline;
>
>        switch (nreq + nopt + rest)
> 	 {
> 	   /* The + 1 is for the smob itself.  */
> 	 case 0:
> 	   trampoline = scm_c_make_gsubr ("apply-smob/0", nreq + 1, nopt, rest,
> 					  apply_0);
> 	   break;
> 	 case 1:
> 	   trampoline = scm_c_make_gsubr ("apply-smob/1", nreq + 1, nopt, rest,
> 					  apply_1);
>
> But I have no idea what it means.
>
> When this happens, guile.exe still runs (actually, there are 2 Guile
> processes, one a child of the other), so it is impossible to delete
> guile-procedures.texi, because one of these processes holds it open.
> I needed to kill guile.exe (the child) to be able to try again.
>
> I tried "make -k" to see how far I can advance.  The next compilation
> of ice-9/eval.scm then stops with the same error:
>
>      make[2]: Entering directory `/d/usr/eli/utils/guile-2.0.9/module'
>        GUILEC ice-9/eval.go
>      wrote `ice-9/eval.go'
>      Backtrace:
>      In unknown file:
> 	?: 3 [apply-smob/1 #<boot-closure 26cca60 (_ _ _)> #t ...]
> 	?: 2 [apply-smob/1 #<catch-closure 2b12100> quit #<unspecified>]
> 	?: 1 [apply-smob/1 #<boot-closure 26cca60 (_ _ _)> #t ...]
> 	?: 0 [apply-smob/1 #<catch-closure 3af6340>]
>
>      ERROR:
>
> Similarly after compiling ice-9/readline.scm:
>
>      wrote `ice-9/readline.go'
>      Backtrace:
>      In unknown file:
> 	?: 4 [apply-smob/1 #<catch-closure 246faf0> quit #<unspecified>]
>      In ice-9/eval.scm:
>       484: 3 [eval # #]
>       481: 2 [lp (#<fluid 13>) (#<procedure 40d9d20 at ice-9/eval.scm:264:7 %args>)]
>      In unknown file:
> 	?: 1 [apply-smob/1 #<catch-closure 3ccb440>]
>      In ice-9/eval.scm:
>       481: 0 [lp (#<fluid 12>) ((#<catch-closure 3ccb420>))]
>
>      ice-9/eval.scm:481:19:
>
> Any ideas?  Where should I look for the source of this problem?
>
> TIA

bug#14361: Building guile 2.0.9 under mingw + msys

[Eli Zaretskii]

> From: Andy Wingo <wingo@pobox.com>
> Cc: 14361-done@debbugs.gnu.org,  ludo@gnu.org
> Date: Mon, 20 Jun 2016 23:19:24 +0200
> 
> Hi Eli :)
> 
> Thank you for your ongoing work on MinGW and Guile, it's really
> appreciated.  I just wanted to say that explicitly here, even though I'm
> closing this bug, as I understand that things have progressed a bit in
> these 3 years; anyway.  Your work is so valuable to many users.  Thanks!

Thanks.

I would be happier, though, if the patch for open-process, whose last
version I submitted here:

  https://lists.gnu.org/archive/html/guile-devel/2014-08/msg00015.html

would be admitted to the repository, as it fixes important
functionality that is currently unavailable in the MinGW build with
upstream sources.  AFAIR, the last communication about this patch was
here:

  https://lists.gnu.org/archive/html/guile-devel/2014-08/msg00024.html
  https://lists.gnu.org/archive/html/guile-devel/2014-08/msg00041.html

I pinged about it a month later:

  https://lists.gnu.org/archive/html/guile-devel/2014-09/msg00066.html

but got no responses.

bug#14361: Building guile 2.0.9 under mingw + msys

[Andy Wingo]

On Tue 21 Jun 2016 14:46, Eli Zaretskii <eliz@gnu.org> writes:

> I would be happier, though, if the patch for open-process, whose last
> version I submitted here:
>
>   https://lists.gnu.org/archive/html/guile-devel/2014-08/msg00015.html
>
> would be admitted to the repository, as it fixes important
> functionality that is currently unavailable in the MinGW build with
> upstream sources.  AFAIR, the last communication about this patch was
> here:
>
>   https://lists.gnu.org/archive/html/guile-devel/2014-08/msg00024.html
>   https://lists.gnu.org/archive/html/guile-devel/2014-08/msg00041.html
>
> I pinged about it a month later:
>
>   https://lists.gnu.org/archive/html/guile-devel/2014-09/msg00066.html
>
> but got no responses.

Let's give it a go!  I understand that you do not want to work with
gnulib.  That's a negative from a Guile POV -- but it's not a
deal-breaker.  The thing we like about Gnulib is that we like working
with POSIX abstractions as much as possible, and we find that it's
easier to do our work as Guile maintainers when we limit and reduce the
number of portability-related shims in our code.  To that end I hesitate
about including a bunch more stuff in posix.c.  Must it all be there, or
would it be possible to move some of it out to our own gnulib-like
mingw-w32.[ch] or something?

Andy

bug#14361: Building guile 2.0.9 under mingw + msys

[Eli Zaretskii]

> From: Andy Wingo <wingo@pobox.com>
> Cc: 14361@debbugs.gnu.org,  ludo@gnu.org
> Date: Tue, 21 Jun 2016 17:06:05 +0200
> 
> Let's give it a go!  I understand that you do not want to work with
> gnulib.  That's a negative from a Guile POV -- but it's not a
> deal-breaker.

I have nothing against Gnulib, but in this case their solution is
simply not up to speed.

> To that end I hesitate about including a bunch more stuff in
> posix.c.  Must it all be there, or would it be possible to move some
> of it out to our own gnulib-like mingw-w32.[ch] or something?

Most of it is already on a separate file, w32-proc.c (see the diffs).
I could take the macros at the beginning of posix.c and put them on a
separate .h file, if that would be better.  The rest of the changes in
posix.c are just moving #ifdef's around, more or less, and a few small
fragments of code, not unlike in other places.  I could, of course,
put them in separate functions, but the advantage of the patch I
pointed to is that it's well tested.

Thanks.

bug#14361: Building guile 2.0.9 under mingw + msys

[Andy Wingo]

On Tue 21 Jun 2016 17:42, Eli Zaretskii <eliz@gnu.org> writes:

>> From: Andy Wingo <wingo@pobox.com>
>> Cc: 14361@debbugs.gnu.org,  ludo@gnu.org
>> Date: Tue, 21 Jun 2016 17:06:05 +0200
>> 
>> Let's give it a go!  I understand that you do not want to work with
>> gnulib.  That's a negative from a Guile POV -- but it's not a
>> deal-breaker.
>
> I have nothing against Gnulib, but in this case their solution is
> simply not up to speed.
>
>> To that end I hesitate about including a bunch more stuff in
>> posix.c.  Must it all be there, or would it be possible to move some
>> of it out to our own gnulib-like mingw-w32.[ch] or something?
>
> Most of it is already on a separate file, w32-proc.c (see the diffs).
> I could take the macros at the beginning of posix.c and put them on a
> separate .h file, if that would be better.

That would be great, if you'd be amenable.  Thanks!

Andy

bug#14361: Building guile 2.0.9 under mingw + msys

[Eli Zaretskii]

> From: Andy Wingo <wingo@pobox.com>
> Cc: 14361@debbugs.gnu.org,  ludo@gnu.org
> Date: Tue, 21 Jun 2016 22:52:37 +0200
> 
> On Tue 21 Jun 2016 17:42, Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> From: Andy Wingo <wingo@pobox.com>
> >> Cc: 14361@debbugs.gnu.org,  ludo@gnu.org
> >> Date: Tue, 21 Jun 2016 17:06:05 +0200
> >> 
> >> Let's give it a go!  I understand that you do not want to work with
> >> gnulib.  That's a negative from a Guile POV -- but it's not a
> >> deal-breaker.
> >
> > I have nothing against Gnulib, but in this case their solution is
> > simply not up to speed.
> >
> >> To that end I hesitate about including a bunch more stuff in
> >> posix.c.  Must it all be there, or would it be possible to move some
> >> of it out to our own gnulib-like mingw-w32.[ch] or something?
> >
> > Most of it is already on a separate file, w32-proc.c (see the diffs).
> > I could take the macros at the beginning of posix.c and put them on a
> > separate .h file, if that would be better.
> 
> That would be great, if you'd be amenable.  Thanks!

Done and posted on guile-devel.

Thanks.