Re: Building the current snapshot on Windows with Guile

[Doug Evans <xdje42 at gmail dot com>]

On Mon, Jun 9, 2014 at 8:24 AM, Eli Zaretskii <eliz@gnu.org> wrote:
> 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?

I guess we'll need a configure option for this.
Some may want a dynamically linked libguile.
[maybe we could add a hack to configure to see whether the --static
arg to pkg-config is necessary]

> 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?

Not sure what to do.

> 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?

There's also the issue of whether to print the messages when loading
user scheme files.
If (*1) we suppressed these messages, we wouldn't want to do a blanket
suppression of user-loaded files.

(*1): As Ludo suggested, we could compile these files during a gdb
build, but that doesn't work in a cross-compilation scenario (without
requiring more complexity in the build, which would be nice to avoid).
Are these files guaranteed to be equivalent across configurations (I'm
guessing not), and if not does guile provide a cross-compiler for them
(I'm guessing not - could be wrong of course)?

I haven't minded the messages - I also get them for my own files.
I understand they would be confusing to random users, especially those
using gdb but not needing guile support - and not even being aware of
(or caring about - which is ok) its presence.

>
> 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\
>

Is --without-python printed if python is not configured in?
[sorry don't have access to sources at the moment - it doesn't seem so
from the above patch, but that's more of a guess]

Plus, IWBN if this was handled identically to python such the only
difference is s/python/guile/ [figuratively speaking].   "Consistency
Is Good."  1/2 :-)