diff mbox

Building the current snapshot on Windows with Guile

Message ID 83y4x614y6.fsf@gnu.org
State New, archived
Headers

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

Joel Brobecker June 9, 2014, 3:39 p.m. UTC | #1 
> 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.
Eli Zaretskii June 9, 2014, 5:30 p.m. UTC | #2 
> 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.
Ludovic Courtès June 9, 2014, 9:04 p.m. UTC | #3 
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’.
Doug Evans June 10, 2014, 7:55 p.m. UTC | #4 
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 :-)
Eli Zaretskii June 10, 2014, 8:26 p.m. UTC | #5 
> 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.
Ludovic Courtès June 11, 2014, 12:24 p.m. UTC | #6 
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’.
Eli Zaretskii June 11, 2014, 2:59 p.m. UTC | #7 
> 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?
Ludovic Courtès June 12, 2014, 8:27 a.m. UTC | #8 
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’.
Eli Zaretskii June 12, 2014, 5:15 p.m. UTC | #9 
> 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.
Ludovic Courtès June 12, 2014, 7:46 p.m. UTC | #10 
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’.
Eli Zaretskii June 12, 2014, 7:58 p.m. UTC | #11 
> 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.
Ludovic Courtès June 13, 2014, 8:35 a.m. UTC | #12 
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’.
Eli Zaretskii June 14, 2014, 6:01 p.m. UTC | #13 
> 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.
diff mbox

Patch

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