guile-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: MinGW issues in Guile 2.0.11


From: Eli Zaretskii
Subject: Re: MinGW issues in Guile 2.0.11
Date: Mon, 09 Jun 2014 18:47:55 +0300

> Date: Sun, 08 Jun 2014 18:04:07 +0300
> From: Eli Zaretskii <address@hidden>
> 
> 4. While looking into this problem, I found and removed the MinGW
>    specific code in canonical_suffix:

That was a mistake, as I now realize: that code is required for
keeping auto-compiled .scm files in the cache, since Windows doesn't
allow colons in file names.  So I retract that part of the patches I
proposed.

A few more issues:

1. version.test always results in UNRESOLVED, because it erroneously
   tests a numeric result with pass-if.  Here's a trivial patch to fix
   that:

--- test-suite/tests/version.test~0     2012-01-31 01:32:38 +0200
+++ test-suite/tests/version.test       2014-06-09 18:05:35 +0300
@@ -24,7 +24,7 @@
         (and (string? (major-version))
              (string? (minor-version))
              (string? (micro-version))
-             (string-contains (version)
-                               (string-append (major-version) "."
-                                              (minor-version) "."
-                                              (micro-version)))))
+             (number? (string-contains (version)
+                                       (string-append (major-version) "."
+                                                      (minor-version) "."
+                                                      (micro-version))))))



2. Building GDB with Guile reveals a problem in the iselect.h header
   file installed by Guile: it includes <sys/select.h>, which doesn't
   exist on MS-Windows.  When Guile is built, that header is provided
   by gnulib, but it isn't (and cannot be) installed.  I propose the
   following to fix the problem:

--- libguile/iselect.h~0        2014-02-15 01:00:33 +0200
+++ libguile/iselect.h  2014-06-09 18:26:52 +0300
@@ -28,7 +28,16 @@
 /* Needed for FD_SET on some systems.  */
 #include <sys/types.h>
 
-#include <sys/select.h>
+#if BUILDING_LIBGUILE
+# include <sys/select.h>
+#else  /* !BUILDING_LIBGUILE */
+# if SCM_HAVE_SYS_SELECT_H
+#  include <sys/select.h>
+# endif
+# if SCM_HAVE_WINSOCK2_H
+#  include <winsock2.h>
+# endif
+#endif /* !BUILDING_LIBGUILE */
 
 SCM_API int scm_std_select (int fds,
                            fd_set *rfds,

3. The nice new feature of auto-loading Guile-specific GDB support
   script when libguile is loaded seems to be useless if the program
   was statically linked with libguile, because the library as such is
   never read by GDB in that case, and so the auto-load hooks never
   trigger.  So the script should be renamed or copied to match the
   program name, or loaded manually.  I think the Guile manual should
   mention that.  In addition, I think the gdbinit file which comes
   with Guile should also be mentioned in the manual, as the commands
   it defines are very useful when debugging Guile on the C level.

4. The libguile built on Windows includes the libcharset.o module
   (taken from gnulib), which is also part of libintl.  This causes
   link failure when statically linking a program (in my case, GDB)
   with Guile, if that program mentions libintl.a before libguile on
   the link command line, because the symbol locale_charset is defined
   twice.  This is a nasty gotcha, and I wish it could be solved,
   because working around it is not easy.  For example, the Guile
   built configury could notice that libintl will be linked in, and
   refrain from including that module from gnulib, even if the
   underlying platform needs some of its code (I think in this case it
   was nl_langinfo).  Alternatively, locale_charset could be declared
   'static', assuming that Guile doesn't call it (gnulib already has a
   provision for doing that).

5. Finally, the auto-compilation message displayed by the library when
   the application loads some .scm file for the first time could
   confuse users.  Here's an example from GDB:

     ;;; note: auto-compilation is enabled, set GUILE_AUTO_COMPILE=0
     ;;;       or pass the --no-auto-compile argument to disable.
     ;;; compiling d:\usr\share\gdb/guile/gdb/boot.scm
     ;;; compiling d:\usr\share\gdb/guile/gdb\init.scm
     ;;; compiled 
D:\usr\eli/.cache/guile/ccache/2.0-LE-4-2.0/d/usr/share/gdb/guile/gdb/init.scm.go
     ;;; compiled 
D:\usr\eli/.cache/guile/ccache/2.0-LE-4-2.0/d/usr/share/gdb/guile/gdb/boot.scm.go

   This talks about a --no-auto-compile switch, which obviously
   doesn't exist except in guile the standalone program.  I wonder
   whether a library should suppress these messages by default.

Thanks.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]