From: Eli Zaretskii <eliz@gnu.org>
To: guile-devel@gnu.org
Subject: MinGW issues in Guile 2.0.11
Date: Sun, 08 Jun 2014 18:04:07 +0300 [thread overview]
Message-ID: <83lht730k8.fsf@gnu.org> (raw)
(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);
next reply other threads:[~2014-06-08 15:04 UTC|newest]
Thread overview: 65+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-08 15:04 Eli Zaretskii [this message]
2014-06-09 15:47 ` MinGW issues in Guile 2.0.11 Eli Zaretskii
2014-06-09 18:01 ` Mark H Weaver
2014-06-09 18:25 ` Eli Zaretskii
2014-06-09 19:30 ` MinGW vs. setlocale Ludovic Courtès
2014-06-10 16:17 ` Eli Zaretskii
2014-06-11 13:13 ` Ludovic Courtès
2014-06-11 15:33 ` Eli Zaretskii
2014-06-12 8:39 ` Ludovic Courtès
2014-06-12 18:18 ` Eli Zaretskii
2014-06-15 17:23 ` Eli Zaretskii
2014-06-21 11:17 ` Eli Zaretskii
2014-06-21 15:02 ` Ludovic Courtès
2014-06-21 15:11 ` Eli Zaretskii
2014-06-21 21:23 ` Ludovic Courtès
2014-06-22 16:13 ` Eli Zaretskii
2014-06-19 4:53 ` Doug Evans
2014-06-19 8:16 ` Ludovic Courtès
2014-06-09 19:32 ` MinGW vs. c-api.test Ludovic Courtès
2014-06-10 9:05 ` Neil Jerram
2014-06-10 11:42 ` Ludovic Courtès
2014-06-10 15:32 ` Eli Zaretskii
2014-06-10 15:56 ` David Kastrup
2014-06-10 18:00 ` Eli Zaretskii
2014-06-11 0:36 ` dsmich
2014-06-11 2:52 ` Eli Zaretskii
2014-06-10 11:44 ` Ludovic Courtès
2014-06-10 15:39 ` Eli Zaretskii
2014-06-11 12:37 ` Ludovic Courtès
2014-06-11 15:08 ` Eli Zaretskii
2014-06-12 8:29 ` Ludovic Courtès
2014-06-12 17:16 ` Eli Zaretskii
2014-06-12 19:48 ` Ludovic Courtès
2014-06-12 19:59 ` Eli Zaretskii
2014-06-12 21:20 ` Ludovic Courtès
2014-06-13 9:15 ` Neil Jerram
2014-06-13 16:04 ` Ludovic Courtès
2014-06-13 16:19 ` Eli Zaretskii
2014-06-13 16:26 ` Neil Jerram
2014-06-13 16:31 ` Mike Gerwitz
2014-06-13 18:09 ` Eli Zaretskii
2014-06-09 19:42 ` Windows file name separators Ludovic Courtès
2014-06-10 16:00 ` Eli Zaretskii
2014-06-30 11:15 ` Ludovic Courtès
2014-06-30 14:56 ` Eli Zaretskii
2014-07-01 9:36 ` Ludovic Courtès
2014-07-01 15:30 ` Eli Zaretskii
2014-07-01 15:38 ` Ludovic Courtès
2014-07-02 16:04 ` Eli Zaretskii
2014-07-02 20:56 ` Ludovic Courtès
2014-07-02 20:57 ` Ludovic Courtès
2014-07-03 15:10 ` Eli Zaretskii
2014-07-03 17:11 ` Ludovic Courtès
2014-07-03 18:09 ` Eli Zaretskii
2014-07-07 20:53 ` Mark H Weaver
2014-07-08 2:37 ` Eli Zaretskii
2014-07-02 16:13 ` Fix 'dirname' and 'basename' on MS-Windows Eli Zaretskii
2014-07-09 14:22 ` Ludovic Courtès
2014-07-09 14:53 ` Eli Zaretskii
2014-07-02 16:16 ` Provide reasonable stack limit " Eli Zaretskii
2014-07-02 21:02 ` Ludovic Courtès
2014-07-03 16:28 ` Eli Zaretskii
2014-07-02 16:30 ` Bug in scm_getaffinity Eli Zaretskii
2014-07-02 21:04 ` Ludovic Courtès
2014-07-03 16:31 ` Eli Zaretskii
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/guile/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=83lht730k8.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=guile-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).