Message ID | 83y4x614y6.fsf@gnu.org |
---|---|
State | New, archived |
Headers |
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: <gdb-patches.sourceware.org> List-Unsubscribe: <mailto:gdb-patches-unsubscribe-##L=##H@sourceware.org> List-Subscribe: <mailto:gdb-patches-subscribe@sourceware.org> List-Archive: <http://sourceware.org/ml/gdb-patches/> List-Post: <mailto:gdb-patches@sourceware.org> List-Help: <mailto:gdb-patches-help@sourceware.org>, <http://sourceware.org/ml/#faqs> 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 <eliz@gnu.org> Subject: Building the current snapshot on Windows with Guile To: Doug Evans <xdje42@gmail.com> Cc: gdb-patches@sourceware.org Reply-to: Eli Zaretskii <eliz@gnu.org> Message-id: <83y4x614y6.fsf@gnu.org> X-IsSubscribed: yes |
Commit Message
Eli Zaretskii
June 9, 2014, 3:24 p.m. UTC
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?
Comments
> 4. Finally, I think we should include the --with-guile indication in > the GDB configuration we display. Any objections to the patch > below? None from me - it seems like a good idea.
> Date: Mon, 9 Jun 2014 17:39:02 +0200 > From: Joel Brobecker <brobecker@adacore.com> > Cc: Doug Evans <xdje42@gmail.com>, gdb-patches@sourceware.org > > > 4. Finally, I think we should include the --with-guile indication in > > the GDB configuration we display. Any objections to the patch > > below? > > None from me - it seems like a good idea. Thanks. I hope to hear at least from Doug before I commit.
Eli Zaretskii <eliz@gnu.org> skribis: > 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 I noticed that too (not MinGW-specific), and it’s annoying, indeed. We should compile these files and install their .go. Ludo’.
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 :-)
> 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.
Doug Evans <xdje42@gmail.com> skribis: > (*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)? It does provide a cross-compiler (info "(guile) Compilation"): guix compile --target=mips64el-linux-gnu foo.scm -o foo.go But note that the interpretation of triplets might defer from that of GDB. In particular, for platforms that support several ABIs with different word sizes, it recognizes some specific triplet extensions–e.g., “mips64el-linux-gnuabi64” for the N64 ABI on MIPS. See <http://git.savannah.gnu.org/cgit/guile.git/tree/module/system/base/target.scm#n76>. Ludo’.
> From: ludo@gnu.org (Ludovic Courtès) > Cc: Eli Zaretskii <eliz@gnu.org>, "gdb-patches\@sourceware.org" <gdb-patches@sourceware.org> > Date: Wed, 11 Jun 2014 14:24:52 +0200 > > Doug Evans <xdje42@gmail.com> skribis: > > > (*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)? > > It does provide a cross-compiler (info "(guile) Compilation"): > > guix compile --target=mips64el-linux-gnu foo.scm -o foo.go > > But note that the interpretation of triplets might defer from that of > GDB. In particular, for platforms that support several ABIs with > different word sizes, it recognizes some specific triplet > extensions–e.g., “mips64el-linux-gnuabi64” for the N64 ABI on MIPS. See > <http://git.savannah.gnu.org/cgit/guile.git/tree/module/system/base/target.scm#n76>. Apart of the issue with multi-ABI platforms, are there any other reasons for the *.go files to be non-portable? E.g., if they were compiled on a 64-bit Windows 7, will they work on a 32-bit Windows XP? Does the answer depend on whether the Guile executable that compiled the *.scm files was a 64-bit or a 32-bit executable? What about compiling on GNU/Linux and using on Windows, when the CPU is the same or from the same family?
Eli Zaretskii <eliz@gnu.org> skribis: >> From: ludo@gnu.org (Ludovic Courtès) >> Cc: Eli Zaretskii <eliz@gnu.org>, "gdb-patches\@sourceware.org" <gdb-patches@sourceware.org> >> Date: Wed, 11 Jun 2014 14:24:52 +0200 >> >> Doug Evans <xdje42@gmail.com> skribis: >> >> > (*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)? >> >> It does provide a cross-compiler (info "(guile) Compilation"): >> >> guix compile --target=mips64el-linux-gnu foo.scm -o foo.go >> >> But note that the interpretation of triplets might defer from that of >> GDB. In particular, for platforms that support several ABIs with >> different word sizes, it recognizes some specific triplet >> extensions–e.g., “mips64el-linux-gnuabi64” for the N64 ABI on MIPS. See >> <http://git.savannah.gnu.org/cgit/guile.git/tree/module/system/base/target.scm#n76>. > > Apart of the issue with multi-ABI platforms, are there any other > reasons for the *.go files to be non-portable? In Guile 2.0, .go files are not portable essentially because sizeof(SCM) is the size of a pointer, and because numbers stored in .go files are in native endianness. (Guile 2.2 uses ELF as its container format, with similar issues.) > E.g., if they were compiled on a 64-bit Windows 7, will they work on a > 32-bit Windows XP? No. > Does the answer depend on whether the Guile executable that compiled > the *.scm files was a 64-bit or a 32-bit executable? No. > What about compiling on GNU/Linux and using on Windows, when the CPU > is the same or from the same family? That works fine. Thanks, Ludo’.
> From: ludo@gnu.org (Ludovic Courtès) > Cc: xdje42@gmail.com, gdb-patches@sourceware.org > Date: Thu, 12 Jun 2014 10:27:12 +0200 > > > Apart of the issue with multi-ABI platforms, are there any other > > reasons for the *.go files to be non-portable? > > In Guile 2.0, .go files are not portable essentially because sizeof(SCM) > is the size of a pointer, and because numbers stored in .go files are in > native endianness. (Guile 2.2 uses ELF as its container format, with > similar issues.) Ouch! That's going to be a drag, IMO. Now I understand why there are no compiled *.go files in the Guile distribution (unlike with Emacs, for example). In that case, I guess it will be impossible to distribute precompiled scm files with the GDB tarball, per your suggestion. Or am I missing something? > > E.g., if they were compiled on a 64-bit Windows 7, will they work on a > > 32-bit Windows XP? > > No. > > > Does the answer depend on whether the Guile executable that compiled > > the *.scm files was a 64-bit or a 32-bit executable? > > No. I'm puzzled: a 32-bit program still produces 32-bit code and uses 32-bit pointers, even when it runs on a 64-bit machine. So why the second "No"? > > What about compiling on GNU/Linux and using on Windows, when the CPU > > is the same or from the same family? > > That works fine. Do the .go files use portable format for numbers? There's a potential issue because a 'long' on a 64-bit GNU/Linux system is a 64-bit quantity, while 64-bit Windows uses 32-bit 'long's. Could this be an issue? Thanks.
Eli Zaretskii <eliz@gnu.org> skribis: >> From: ludo@gnu.org (Ludovic Courtès) >> Cc: xdje42@gmail.com, gdb-patches@sourceware.org >> Date: Thu, 12 Jun 2014 10:27:12 +0200 >> >> > Apart of the issue with multi-ABI platforms, are there any other >> > reasons for the *.go files to be non-portable? >> >> In Guile 2.0, .go files are not portable essentially because sizeof(SCM) >> is the size of a pointer, and because numbers stored in .go files are in >> native endianness. (Guile 2.2 uses ELF as its container format, with >> similar issues.) > > Ouch! That's going to be a drag, IMO. Now I understand why there are > no compiled *.go files in the Guile distribution (unlike with Emacs, > for example). > > In that case, I guess it will be impossible to distribute precompiled > scm files with the GDB tarball, per your suggestion. Or am I missing > something? I was not suggesting to distribute the .go files; rather, I was suggesting to add makefile rules to build them and install them. >> > E.g., if they were compiled on a 64-bit Windows 7, will they work on a >> > 32-bit Windows XP? >> >> No. >> >> > Does the answer depend on whether the Guile executable that compiled >> > the *.scm files was a 64-bit or a 32-bit executable? >> >> No. > > I'm puzzled: a 32-bit program still produces 32-bit code and uses > 32-bit pointers, even when it runs on a 64-bit machine. So why the > second "No"? Oh you’re right, sorry for the confusion. What matters is sizeof(SCM). >> > What about compiling on GNU/Linux and using on Windows, when the CPU >> > is the same or from the same family? >> >> That works fine. > > Do the .go files use portable format for numbers? Yes (info "(guile) Data Constructor Instructions"). > There's a potential issue because a 'long' on a 64-bit GNU/Linux > system is a 64-bit quantity, while 64-bit Windows uses 32-bit 'long's. > Could this be an issue? Nope. The ‘make-intXX’ VM instructions are independent of the C type definitions. Guile supports bignums and those can be also be stored safely in compiled files (info "(guile) Loading Instructions"). I hope this clarifies things. Ludo’.
> From: ludo@gnu.org (Ludovic Courtès) > Cc: xdje42@gmail.com, gdb-patches@sourceware.org > Date: Thu, 12 Jun 2014 21:46:24 +0200 > > I was not suggesting to distribute the .go files; rather, I was > suggesting to add makefile rules to build them and install them. Sorry, my misunderstanding. Perhaps you could propose patches to do that, as GDB 7.8 is on its way to be released in a few weeks. > I hope this clarifies things. It does, thanks.
Eli Zaretskii <eliz@gnu.org> skribis: >> From: ludo@gnu.org (Ludovic Courtès) >> Cc: xdje42@gmail.com, gdb-patches@sourceware.org >> Date: Thu, 12 Jun 2014 21:46:24 +0200 >> >> I was not suggesting to distribute the .go files; rather, I was >> suggesting to add makefile rules to build them and install them. > > Sorry, my misunderstanding. Perhaps you could propose patches to do > that, as GDB 7.8 is on its way to be released in a few weeks. Yes, I’ll see what I can do. Ludo’.
> Date: Mon, 9 Jun 2014 17:39:02 +0200 > From: Joel Brobecker <brobecker@adacore.com> > Cc: Doug Evans <xdje42@gmail.com>, gdb-patches@sourceware.org > > > 4. Finally, I think we should include the --with-guile indication in > > the GDB configuration we display. Any objections to the patch > > below? > > None from me - it seems like a good idea. No further comments, so I committed this to both master and the 7.8 branch. Thanks.
--- 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\