Building the current snapshot on Windows with Guile

[Eli Zaretskii <eliz at gnu dot org>]

I succeeded in building a MinGW GDB with Guile.  Here are some issues
I uncovered while doing that:

1. configure doesn't find Guile because the test program fails.  This
   happens because the configure script uses "pkg-config --libs" to
   find the linker switches required to link a program with libguile.
   But this is only sufficient for dynamic linking; for linking
   statically, one need to invoke "pkg-config --libs --static"
   instead.  The result of not using --static is that not all of the
   prerequisite -lFOO switches are passed to the linker, and a static
   link fails.  As luck would have it, my libguile is a static
   library.

   I hacked around this by manually editing gdb/configure to use
   --static, but I wonder what would be a proper solution.  Always use
   --static and risk some extra linker switches?

2. Link failed because both libintl.a and libguile-2.0.a define a
   function named `locale_charset'.  This might be actually a Guile
   problem (I will raise that on guile-devel), but it made me wonder
   why does intl/config.intl insist on using /usr/lib/libintl.a
   somewhere at the beginning of the link command, instead of using
   -lintl at the end?  Guile needs libintl anyway, so even omitting
   libintl.a from the command line is enough to solve the potential
   problem.

   Thoughts?

3. Running GDB, you see this on the first invocation:

     ;;; 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
     GNU gdb (GDB) 7.7.50.20140608-cvs

   It took me a few minutes to realize that --no-auto-compile is not a
   GDB option, but rather a Guile option, so the only way to avoid
   this auto-compilation is by setting GUILE_AUTO_COMPILE=0 in the
   environment.  I wonder whether we should provide this option, just
   so users don't become confused by the message (which IMO is also a
   Guile issue: a library shouldn't cite any command-line switches).
   Or maybe we should simply suppress this message (assuming there's a
   way of doing that), to avoid presenting the user with something
   they don't expect and don't necessarily understand.

   Also, I was surprised to see the compiled files be named as
   FOO.scm.go, rather than just FOO.go.  At first I thought it was
   some Windows-specific snafu with file names, but stepping through
   the relevant libguile code seems to indicate that it indeed appends
   the .go suffix without removing .scm.  So maybe GDB specific
   initialization should specify the file without the .scm suffix?

4. Finally, I think we should include the --with-guile indication in
   the GDB configuration we display.  Any objections to the patch
   below?

--- gdb/top.c~0	2014-06-08 04:48:23 +0300
+++ gdb/top.c	2014-06-09 18:40:31 +0300
@@ -1188,6 +1188,15 @@ This GDB was configured as follows:\n\
              --with-python=%s%s\n\
 "), WITH_PYTHON_PATH, PYTHON_PATH_RELOCATABLE ? " (relocatable)" : "");
 #endif
+#if HAVE_GUILE
+  fprintf_filtered (stream, _("\
+             --with-guile\n\
+"));
+#else
+  fprintf_filtered (stream, _("\
+             --without-guile\n\
+"));
+#endif
 #ifdef RELOC_SRCDIR
   fprintf_filtered (stream, _("\
              --with-relocated-sources=%s\n\