From patchwork Mon Jun 9 15:24:33 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Eli Zaretskii X-Patchwork-Id: 1380 Received: (qmail 14268 invoked by alias); 9 Jun 2014 15:24:40 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Delivered-To: mailing list gdb-patches@sourceware.org Received: (qmail 14256 invoked by uid 89); 9 Jun 2014 15:24:39 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.8 required=5.0 tests=AWL, BAYES_00, RCVD_IN_DNSWL_NONE, SPF_SOFTFAIL, T_HDRS_LCASE autolearn=no version=3.3.2 X-HELO: mtaout20.012.net.il Received: from mtaout20.012.net.il (HELO mtaout20.012.net.il) (80.179.55.166) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 09 Jun 2014 15:24:38 +0000 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0N6W00200QQKLQ00@a-mtaout20.012.net.il> for gdb-patches@sourceware.org; Mon, 09 Jun 2014 18:24:35 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0N6W002WDQSYGL50@a-mtaout20.012.net.il>; Mon, 09 Jun 2014 18:24:35 +0300 (IDT) Date: Mon, 09 Jun 2014 18:24:33 +0300 From: Eli Zaretskii Subject: Building the current snapshot on Windows with Guile To: Doug Evans Cc: gdb-patches@sourceware.org Reply-to: Eli Zaretskii Message-id: <83y4x614y6.fsf@gnu.org> X-IsSubscribed: yes 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\