This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: Building the current snapshot on Windows with Guile
- From: Eli Zaretskii <eliz at gnu dot org>
- To: Doug Evans <xdje42 at gmail dot com>
- Cc: ludo at gnu dot org, gdb-patches at sourceware dot org
- Date: Tue, 10 Jun 2014 23:26:51 +0300
- Subject: Re: Building the current snapshot on Windows with Guile
- Authentication-results: sourceware.org; auth=none
- References: <83y4x614y6 dot fsf at gnu dot org> <CAP9bCMQHCL7Riah5Z-M4Puo=qi1QLcv_Z6fVB8p=RdzLaNoUwQ at mail dot gmail dot com>
- Reply-to: Eli Zaretskii <eliz at gnu dot org>
> Date: Tue, 10 Jun 2014 12:55:09 -0700
> From: Doug Evans <xdje42@gmail.com>
> Cc: "gdb-patches@sourceware.org" <gdb-patches@sourceware.org>
>
> 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]
We could, for example, try without --static, then with it, if the 1st
attempt fails.
> 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.
Why not? I think Python does that silently, doesn't it?
> (*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)?
There's some dependence on architecture, which I don't think I
understand enough about (but Ludovic certainly does).
> > --- 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?
No, we just omit the --without-python. But --without-python has an
argument, whereas --with-guile normally won't. Also, we display
--without-FOO for other features, like --without-lzma.
I don't think the minor difference wrt Python matters here, and it's
not without a reason.