MinGW issues in Guile 2.0.11

[Eli Zaretskii]

(Disappointed by lack of responses, but not enough to refrain from
reporting more problems.)

Running the Guile test suite on MS-Windows reveals the following
issues:

1. i18n.test completely fails, because it depends on the ability to
   change the program's locale at run time.  I wish this whole test
   were skipped on Windows.  (I'm quite sure I reported this last
   year.)

2. c-api.test fails with many messages such as this one:

     'CUR' is not recognized as an internal or external command,
     operable program or batch file.

   This is because c-api.test does this:

     (define (egrep string filename)
       (zero? (system (string-append "egrep '" string "' " filename " 
>/dev/null"))))
     ...
                 (if (and (file-exists? file)
                          (egrep "SEEK_(SET|CUR|END)" file))

   There are two problems here: quoting that is not supported by
   Windows shells, and redirection to /dev/null.  The former is easily
   fixed portably:

     (system (string-append "egrep \"" string \"" " filename

   The latter requires either an OS-dependent string in the *.scm
   source of the test, or a variable (called, e.g., null-device) that
   will be set correctly for each platform, which could then be used
   by the test unconditionally.

3. load.test fails:

     FAIL: load.test: search-path for "foo.scm" yields "dir1/foo.scm"

   (The messages are misleading: "yields" should be "should yield".)

   The test fails because:

    . it compares file names with equal?, which fails when Windows
      file names with mixed forward and backslashes are used, and/or
      when the files differ but for letter case

    . the expected result uses a relative file name of temp-dir, while
      search-path returns absolute file names

   Fixed by using "/" to create a file name from its parts in load.c:

--- libguile/load.c~    2014-02-28 23:01:27 +0200
+++ libguile/load.c     2014-06-08 13:27:24 +0300
@@ -452,11 +452,15 @@ scm_c_string_has_an_ext (char *str, size
   return 0;
 }
 
+#if 0
 #ifdef __MINGW32__
 #define FILE_NAME_SEPARATOR_STRING "\\"
 #else
 #define FILE_NAME_SEPARATOR_STRING "/"
 #endif
+#else
+#define FILE_NAME_SEPARATOR_STRING "/"
+#endif
 
 static int
 is_file_name_separator (SCM c)

   I don't see any reasons to use the backslashes when constructing
   Windows file names.  Unless someone can tell why using backslashes
   is a good idea, I propose to remove the Windows setting of
   FILE_NAME_SEPARATOR_STRING.

4. While looking into this problem, I found and removed the MinGW
   specific code in canonical_suffix:

@@ -877,23 +881,6 @@ canonical_suffix (SCM fname)
 
   /* CANON should be absolute.  */
   canon = scm_canonicalize_path (fname);
-  
-#ifdef __MINGW32__
-  {
-    size_t len = scm_c_string_length (canon);
-
-    /* On Windows, an absolute file name that doesn't start with a
-       separator starts with a drive component.  Transform the drive
-       component to a file name element: c:\foo -> \c\foo. */
-    if (len >= 2
-        && is_absolute_file_name (canon)
-        && !is_file_name_separator (scm_c_string_ref (canon, 0)))
-      return scm_string_append
-        (scm_list_3 (scm_from_latin1_string (FILE_NAME_SEPARATOR_STRING),
-                     scm_c_substring (canon, 0, 1),
-                     scm_c_substring (canon, 2, len)));
-  }
-#endif

   I think this is not a good idea, because the resulting \c\foo\bar
   file name is then passed to C APIs which cannot possibly find such
   files.  This file-name syntax is only supported by MSYS runtime,
   MinGW programs know nothing about this.  Suggest to remove.

5. ftw.scm invents absolute-file-name?, and does it wrong.  Suggest to
   fix:

--- module/ice-9/ftw.scm~0      2014-02-21 00:58:22 +0200
+++ module/ice-9/ftw.scm        2014-06-08 07:38:10 +0300
@@ -222,6 +222,7 @@
         (loop (cdr nodes) (string-append result "/" (car nodes))))))
 
 (define (abs? filename)
-  (char=? #\/ (string-ref filename 0)))
+  (absolute-file-name? filename))
 
 ;; `visited?-proc' returns a test procedure VISITED? which when called as
 ;; (VISITED? stat-obj) returns #f the first time a distinct file is seen,

6. 'times', 'sleep' and 'usleep' were not working, so time.test
   failed.  The fixes are in gnulib, let's hope the gnulib maintainers
   will accept them.

   Btw, the documented return value of 'sleep' and 'usleep' relies on
   the assumption that 'select' zeroes out its timeout argument when
   the waiting period expires and no data or signal arrives.  AFAIU,
   this assumption is not portable; in particular the gnulib
   implementation does not guarantee that.

7. Another reason for failed tests in time.test is the unportable code
   that sets TZ in the environment to force a timezone change.  The
   way it does that completely confuses the MinGW runtime, so I needed
   to disable that part for MinGW, which at least lets it pass all but
   1 test.  Here's the patch:

--- libguile/stime.c~0  2014-06-08 12:12:56 +0300
+++ libguile/stime.c    2014-06-08 13:03:01 +0300
@@ -682,6 +682,10 @@ SCM_DEFINE (scm_strftime, "strftime", 2,
 
   tbuf = scm_malloc (size);
   {
+#ifndef __MINGW32__
+    /* Don't do this for MinGW: it only supports fixed-format
+       TTTnnnDDD TZ specifications, and gets confused if a zero is
+       appended.  */
 #if !defined (HAVE_TM_ZONE)
     /* it seems the only way to tell non-GNU versions of strftime what
        zone to use (for the %Z format) is to set TZ in the
@@ -706,6 +710,7 @@ SCM_DEFINE (scm_strftime, "strftime", 2,
        oldenv = setzone (zone, SCM_ARG2, FUNC_NAME);
       }
 #endif
+#endif
 
 #ifdef LOCALTIME_CACHE
     tzset ();
@@ -720,6 +725,7 @@ SCM_DEFINE (scm_strftime, "strftime", 2,
        tbuf = scm_malloc (size);
       }
 
+#ifndef __MINGW32__
 #if !defined (HAVE_TM_ZONE)
     if (have_zone)
       {
@@ -727,6 +733,7 @@ SCM_DEFINE (scm_strftime, "strftime", 2,
        SCM_CRITICAL_SECTION_END;
       }
 #endif
+#endif
     }
 
   result = scm_from_utf8_string (tbuf + 1);