[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.
- MinGW issues in Guile 2.0.11, Eli Zaretskii, 2014/06/08
- Re: MinGW issues in Guile 2.0.11,
Eli Zaretskii <=
- 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
- Re: MinGW vs. setlocale, Eli Zaretskii, 2014/06/21