[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
MinGW issues in Guile 2.0.11
From: |
Eli Zaretskii |
Subject: |
MinGW issues in Guile 2.0.11 |
Date: |
Sun, 08 Jun 2014 18:04:07 +0300 |
(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);
- MinGW issues in Guile 2.0.11,
Eli Zaretskii <=
- Re: MinGW issues in Guile 2.0.11, Eli Zaretskii, 2014/06/09
- Re: MinGW issues in Guile 2.0.11, Mark H Weaver, 2014/06/09
- MinGW vs. setlocale, Ludovic Courtès, 2014/06/09
- Re: MinGW vs. setlocale, Eli Zaretskii, 2014/06/10
- Re: MinGW vs. setlocale, Ludovic Courtès, 2014/06/11
- Re: MinGW vs. setlocale, Eli Zaretskii, 2014/06/11
- Re: MinGW vs. setlocale, Ludovic Courtès, 2014/06/12
- Re: MinGW vs. setlocale, Eli Zaretskii, 2014/06/12
- Re: MinGW vs. setlocale, Eli Zaretskii, 2014/06/15