GDB version 7.12.1 (January 2017 tarball) does not compile with the latest guile (version 2.1.6) -- it appears that gdb is using a variety of functions that are now deprecated, and accessing structures that are no longer externally visible. For example: ../../gdb/guile/scm-ports.c:1097:41: error: invalid use of incomplete type ‘scm_t_port {aka struct scm_t_port}’ no surprise -- struct scm_t_port is no longer defined in libguile/ports.h -- there's only a forward declaration, and the structure itself is now opaque.
I confirm that the issue exists at Arch Linux if I try to compile gdb with guile 2.2 ./guile/scm-ports.c:1097:41: error: invalid use of incomplete type ‘scm_t_port {aka struct scm_t_port}’ pt->write_end = pt->write_buf + pt->write_buf_size; ^~ In file included from /usr/include/guile/2.2/libguile/fports.h:28:0, from /usr/include/guile/2.2/libguile.h:57, from ./guile/guile-internal.h:29, from ./guile/scm-ports.c:28: /usr/include/guile/2.2/libguile/ports.h:82:16: note: forward declaration of ‘scm_t_port {aka struct scm_t_port}’ typedef struct scm_t_port scm_t_port; ^~~~~~~~~~ make[2]: *** [Makefile:2537: scm-ports.o] Error 1 make[2]: *** Waiting for unfinished jobs.... make[2]: Leaving directory '/build/avr-gdb/src/gdb-7.12.1/gdb' make[1]: *** [Makefile:9161: all-gdb] Error 2 make[1]: Leaving directory '/build/avr-gdb/src/gdb-7.12.1' make: *** [Makefile:850: all] Error 2 Do you plan to port gdb to the new guile API? Is there a workaround that can we use to prevent this compilation issue?
I am not aware of anyone working on this, but contributions are always welcome. I don't use Guile myself and am not familiar with the concepts, so it would be difficult for me to do it.
For me a "workaround" is to explicitly disable guile by passing `--with-guile=no` to GDB's configure script.
An ArchLinux user reported this via RTEMS so I wanted to ask some questions. Is this a problem with gdb 8? Is there a way to detect the newer guile via autoconf and automatically disable it? And the basic question of... What is guile even used for? :)
> Is this a problem with gdb 8? Most likely yes, as in ArchLinux GDB 8.0 is build with older version of guile (2.0). > And the basic question of... What is guile even used for? :) From my understanding guile is used for the very same thing as python - you can write guile (scheme) scripts in it and GDB will be able to understand them.
(In reply to Freddie Chopin from comment #5) > > Is this a problem with gdb 8? > > Most likely yes, as in ArchLinux GDB 8.0 is build with older version of > guile (2.0). Hmm... RTEMS has something we call the RTEMS Source Builder which is logically comparable to BSD ports. The user uses it to automate fetching all the source, applying patches, and building tools. That gives us two options: + add building a known guile as part of building gdb + disable guile. > > And the basic question of... What is guile even used for? :) > > From my understanding guile is used for the very same thing as python - you > can write guile (scheme) scripts in it and GDB will be able to understand > them. Thanks. I don't want to get into an Internet war over guile vs Python but personally I would lean to disabling guile for RTEMS.
The master branch has been updated by Simon Marchi <simark@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=6e66f7538112d2f5fb1af17dbde33ba37a7171be commit 6e66f7538112d2f5fb1af17dbde33ba37a7171be Author: Simon Marchi <simon.marchi@polymtl.ca> Date: Mon Oct 9 12:50:58 2017 -0400 Don't try building gdb against guile-2.2 GDB currently doesn't build with Guile 2.2 (see PR 21104). If one has both Guile 2.2 and 2.0 installed, GDB will pick up Guile 2.2 first and fail building. Until somebody does the work of adapting the GDB code to Guile 2.2, we should not try using it. This patch therefore removes it from configure. gdb/ChangeLog: * configure.ac (try_guile_versions): Remove guile-2.2. * configure: Regenerate.
Is guile 2.1.x something we need to support going forward? It's not available for download on ftp.gnu.org. I ask because I have a patch for >= 2.2. https://sourceware.org/ml/gdb-patches/2018-01/msg00438.html
(In reply to dje from comment #8) > Is guile 2.1.x something we need to support going forward? > It's not available for download on ftp.gnu.org. The two current tracks seem to be 2.0 (Legacy) and 2.2 (Current). I see no mention of 2.1. So I guess we won't have to support it. Are they using a numbering scheme where odd dot-numbers are used for testing releases?
Created attachment 10757 [details] attachment-123636-0.html On Mon, Jan 22, 2018 at 9:31 AM, simon.marchi at ericsson dot com < sourceware-bugzilla@sourceware.org> wrote: > https://sourceware.org/bugzilla/show_bug.cgi?id=21104 > > Are they using a numbering scheme where odd dot-numbers are used for > testing > releases? > Yes. guile-2.1 was an experimental development branch, and is not supported by the guile team.
guile commit 9a9e0cceae has made buffer fields private and seems there is no non-internal API to manipulate it. Adding Andy Wingo who made the guile change. Andy, could you please help to make a fix for gdb?
Any news here? guile 2.0 doesn't pass tests in Fedora so we either need to fix it or port gdb to guile 2.2.
Would someone be able to review comment #8? I had written a patch of my own before I noticed that I was beaten to the punch almost two years ago! (In reply to Anatol Pomozov from comment #11) > guile commit 9a9e0cceae has made buffer fields private and seems there is no > non-internal API to manipulate it. Does this matter? AFAICT, most of the removed API involves stuff that should have been internal to libguile to start with (managing buffers and cursors, figuring out when to flush, flushing read buffers when moving to write mode and vice-versa, etc). The removed API makes it difficult to port memory-port-read-buffer-size et al, but besides that it should present an opportunity to simplify the implementation considerably.
The patch mentioned in comment 8 was submitted for inclusion here https://sourceware.org/ml/gdb-patches/2018-02/msg00093.html but was not followed up on. It still applies cleanly, but it doesn't build, so we would need somebody to refresh and submit it again.
*** Bug 23918 has been marked as a duplicate of this bug. ***
This guile incompatibility issue still exists in the latest version of GDB. GDB folks, do you have any estimation when this issue could be fixed?
(In reply to Anatol Pomozov from comment #16) > This guile incompatibility issue still exists in the latest version of GDB. > > GDB folks, do you have any estimation when this issue could be fixed? No, nobody's working on it AFAIK.
(In reply to Simon Marchi from comment #17) > (In reply to Anatol Pomozov from comment #16) > > This guile incompatibility issue still exists in the latest version of GDB. > > > > GDB folks, do you have any estimation when this issue could be fixed? > > No, nobody's working on it AFAIK. Update: patch submitted: https://sourceware.org/pipermail/gdb-patches/2020-June/169435.html
The master branch has been updated by Simon Marchi <simark@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=68cf161c24b096608bf4a1b97b489cc7277bffc0 commit 68cf161c24b096608bf4a1b97b489cc7277bffc0 Author: Ludovic Courtès <ludo@gnu.org> Date: Sun Jun 28 16:25:39 2020 +0200 guile: Add support for Guile 2.2. This primarily updates code that uses the I/O port API of Guile. gdb/ChangeLog 2020-06-28 Ludovic Courtès <ludo@gnu.org> Doug Evans <dje@google.com> PR gdb/21104 * guile/scm-ports.c (USING_GUILE_BEFORE_2_2): New macro. (ioscm_memory_port)[read_buf_size, write_buf_size]: Wrap in #if USING_GUILE_BEFORE_2_2. (stdio_port_desc, memory_port_desc) [!USING_GUILE_BEFORE_2_2]: Change type to 'scm_t_port_type *'. (natural_buffer_size) [!USING_GUILE_BEFORE_2_2]: New variable. (ioscm_open_port) [USING_GUILE_BEFORE_2_2]: Add 'stream' parameter and honor it. Update callers. (ioscm_open_port) [!USING_GUILE_BEFORE_2_2]: New function. (ioscm_read_from_port, ioscm_write) [!USING_GUILE_BEFORE_2_2]: New functions. (ioscm_fill_input, ioscm_input_waiting, ioscm_flush): Wrap in #if USING_GUILE_BEFORE_2_2. (ioscm_init_gdb_stdio_port) [!USING_GUILE_BEFORE_2_2]: Use 'ioscm_read_from_port'. Call 'scm_set_port_read_wait_fd'. (ioscm_init_stdio_buffers) [!USING_GUILE_BEFORE_2_2]: New function. (gdbscm_stdio_port_p) [!USING_GUILE_BEFORE_2_2]: Use 'SCM_PORTP' and 'SCM_PORT_TYPE'. (gdbscm_memory_port_end_input, gdbscm_memory_port_seek) (ioscm_reinit_memory_port): Wrap in #if USING_GUILE_BEFORE_2_2. (gdbscm_memory_port_read, gdbscm_memory_port_write) (gdbscm_memory_port_seek, gdbscm_memory_port_close) [!USING_GUILE_BEFORE_2_2]: New functions. (gdbscm_memory_port_print): Remove use of 'SCM_PTOB_NAME'. (ioscm_init_memory_port_type) [!USING_GUILE_BEFORE_2_2]: Use 'gdbscm_memory_port_read'. Wrap 'scm_set_port_end_input', 'scm_set_port_flush', and 'scm_set_port_free' calls in #if USING_GUILE_BEFORE_2_2. (gdbscm_get_natural_buffer_sizes) [!USING_GUILE_BEFORE_2_2]: New function. (ioscm_init_memory_port): Remove. (ioscm_init_memory_port_stream): New function (ioscm_init_memory_port_buffers) [USING_GUILE_BEFORE_2_2]: New function. (gdbscm_memory_port_read_buffer_size) [!USING_GUILE_BEFORE_2_2]: Return scm_from_uint (0). (gdbscm_set_memory_port_read_buffer_size_x) [!USING_GUILE_BEFORE_2_2]: Call 'scm_setvbuf'. (gdbscm_memory_port_write_buffer_size) [!USING_GUILE_BEFORE_2_2]: Return scm_from_uint (0). (gdbscm_set_memory_port_write_buffer_size_x) [!USING_GUILE_BEFORE_2_2]: Call 'scm_setvbuf'. * configure.ac (try_guile_versions): Add "guile-2.2". * configure: Regenerate. * NEWS: Add entry. gdb/testsuite/ChangeLog 2020-06-28 Ludovic Courtès <ludo@gnu.org> * gdb.guile/scm-error.exp ("source $remote_guile_file_1"): Relax error regexp to match on Guile 2.2. gdb/doc/ChangeLog 2020-06-28 Ludovic Courtès <ludo@gnu.org> * guile.texi (Memory Ports in Guile): Mark 'memory-port-read-buffer-size', 'set-memory-port-read-buffer-size!', 'memory-port-write-buffer-size', 'set-memory-port-read-buffer-size!' as deprecated. * doc/guile.texi (Guile Introduction): Clarify which Guile versions are supported. Change-Id: Ib119b10a2787446e0ae482a5e1b36d809c44bb31
Thanks Ludovic for the patches, this can now be closed. Please open a new bug for any new issue that comes up related to this.