This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Building the current snapshot on Windows with Guile


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]