> Date: Sun, 08 Jun 2014 18:04:07 +0300 > From: Eli Zaretskii <e...@gnu.org> > > 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.