From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.lisp.guile.devel Subject: MinGW issues in Guile 2.0.11 Date: Sun, 08 Jun 2014 18:04:07 +0300 Message-ID: <83lht730k8.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1402239882 5383 80.91.229.3 (8 Jun 2014 15:04:42 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 8 Jun 2014 15:04:42 +0000 (UTC) To: guile-devel@gnu.org Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Sun Jun 08 17:04:31 2014 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Wtee7-0002px-33 for guile-devel@m.gmane.org; Sun, 08 Jun 2014 17:04:31 +0200 Original-Received: from localhost ([::1]:56735 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wtee6-0007Kj-N3 for guile-devel@m.gmane.org; Sun, 08 Jun 2014 11:04:30 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55546) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wtedx-0007KS-GG for guile-devel@gnu.org; Sun, 08 Jun 2014 11:04:28 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Wtedp-00052B-N0 for guile-devel@gnu.org; Sun, 08 Jun 2014 11:04:21 -0400 Original-Received: from mtaout28.012.net.il ([80.179.55.184]:43294) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wtedp-000522-9n for guile-devel@gnu.org; Sun, 08 Jun 2014 11:04:13 -0400 Original-Received: from conversion-daemon.mtaout28.012.net.il by mtaout28.012.net.il (HyperSendmail v2007.08) id <0N6U00200UYIV300@mtaout28.012.net.il> for guile-devel@gnu.org; Sun, 08 Jun 2014 18:02:27 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout28.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0N6U001R0V439920@mtaout28.012.net.il> for guile-devel@gnu.org; Sun, 08 Jun 2014 18:02:27 +0300 (IDT) X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 80.179.55.184 X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:17190 Archived-At: (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);