From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5108 invoked by alias); 10 Jun 2014 19:55:14 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 5093 invoked by uid 89); 10 Jun 2014 19:55:13 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-yh0-f42.google.com Received: from mail-yh0-f42.google.com (HELO mail-yh0-f42.google.com) (209.85.213.42) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Tue, 10 Jun 2014 19:55:11 +0000 Received: by mail-yh0-f42.google.com with SMTP id i57so3259632yha.1 for ; Tue, 10 Jun 2014 12:55:10 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.236.62.130 with SMTP id y2mr4008509yhc.158.1402430109903; Tue, 10 Jun 2014 12:55:09 -0700 (PDT) Received: by 10.170.150.70 with HTTP; Tue, 10 Jun 2014 12:55:09 -0700 (PDT) In-Reply-To: <83y4x614y6.fsf@gnu.org> References: <83y4x614y6.fsf@gnu.org> Date: Tue, 10 Jun 2014 19:55:00 -0000 Message-ID: Subject: Re: Building the current snapshot on Windows with Guile From: Doug Evans To: Eli Zaretskii , =?UTF-8?Q?Ludovic_Court=C3=A8s?= Cc: "gdb-patches@sourceware.org" Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2014-06/txt/msg00430.txt.bz2 On Mon, Jun 9, 2014 at 8:24 AM, Eli Zaretskii 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 :-)