Bug 21104 - 7.12.1 does not compile with latest guile (2.1.6)
Summary: 7.12.1 does not compile with latest guile (2.1.6)
Status: NEW
Alias: None
Product: gdb
Classification: Unclassified
Component: guile (show other bugs)
Version: 7.12.1
: P2 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-02-02 21:27 UTC by Linas Vepstas
Modified: 2019-11-24 03:46 UTC (History)
11 users (show)

See Also:
Host:
Target:
Build:
Last reconfirmed: 2019-11-24 00:00:00


Attachments
attachment-123636-0.html (503 bytes, text/html)
2018-01-22 15:37 UTC, Linas Vepstas
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Linas Vepstas 2017-02-02 21:27:15 UTC
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.
Comment 1 Anatol Pomozov 2017-03-29 14:10:12 UTC
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?
Comment 2 Simon Marchi 2017-04-26 04:31:19 UTC
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.
Comment 3 Freddie Chopin 2017-05-02 21:23:58 UTC
For me a "workaround" is to explicitly disable guile by passing `--with-guile=no` to GDB's configure script.
Comment 4 Joel Sherrill 2017-06-28 16:11:22 UTC
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? :)
Comment 5 Freddie Chopin 2017-06-28 16:19:08 UTC
> 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.
Comment 6 Joel Sherrill 2017-06-28 16:24:00 UTC
(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.
Comment 7 cvs-commit@gcc.gnu.org 2017-10-09 16:52:58 UTC
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.
Comment 8 dje 2018-01-22 07:13:05 UTC
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
Comment 9 Simon Marchi 2018-01-22 15:31:45 UTC
(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?
Comment 10 Linas Vepstas 2018-01-22 15:37:11 UTC
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.
Comment 11 Anatol Pomozov 2018-01-29 03:28:54 UTC
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?
Comment 12 Igor Gnatenko 2019-02-17 21:31:07 UTC
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.
Comment 13 bob 2019-11-24 03:05:23 UTC
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.
Comment 14 Simon Marchi 2019-11-24 03:46:04 UTC
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.