Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Tom Tromey <tom@tromey.com>
To: Andrew Burgess <aburgess@redhat.com>
Cc: Tom Tromey <tom@tromey.com>,
	 gcc-patches@gcc.gnu.org, gdb-patches@sourceware.org
Subject: Re: [PATCH] Revert "Pass GUILE down to subdirectories"
Date: Fri, 08 Mar 2024 11:03:23 -0700	[thread overview]
Message-ID: <874jdgr47o.fsf@tromey.com> (raw)
In-Reply-To: <877cifbr60.fsf@redhat.com> (Andrew Burgess's message of "Wed, 06 Mar 2024 10:17:27 +0000")

>>>>> "Andrew" == Andrew Burgess <aburgess@redhat.com> writes:

Andrew> After once again forgetting to add GUILE=guile2.2 to my GDB build I was
Andrew> thinking about this issue again.

Andrew> Given that GDB has a --with-guile=... configure option, and that our
Andrew> configure scripts try to identify a matching version of guild and a
Andrew> shared library to link GDB against, I wondered why we don't just force
Andrew> the use of a matching version of guile.

Andrew> I guess I'm suggesting that for building GDB's guile components we
Andrew> should respect either the --with-guile=... configure option, or what the
Andrew> configure script auto-detected, and should not be picking up any build
Andrew> time GUILE=... flag -- setting GUILE=... isn't going to change the
Andrew> version of guild used, nor is it going to change the shared library that
Andrew> GDB links against, so just changing the guile version seems like a
Andrew> recipe for incompatibility problems.

Andrew> Below is a patch that forces GDB to compile our guile scripts using a
Andrew> suitable version of guile.  This could be applied irrespective of
Andrew> whether you revert b7e5a29602143b53267efcd9c8d5ecc78cd5a62f or not.

Andrew> What do you think?

I have no issue with this.  If it helps you, you should do it.

FWIW I was waiting for a response from you before reverting this change.
https://sourceware.org/pipermail/gdb-patches/2024-February/206507.html


Overall I think that we really should revert my change.

cgen isn't run commonly enough to warrant the change breaking literally
anything else.  And, part of this is on cgen for not coming with any
kind of script for running it ... actually looking under the hood has
really soured me on cgen entirely.

The guild #! prologue also seems like an obvious bug to me.  However
it's perhaps too late to fix this in any useful way.

Tom

      reply	other threads:[~2024-03-08 18:03 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-23  0:19 Tom Tromey
2024-02-07 16:09 ` Andrew Burgess
2024-02-10 21:54   ` Tom Tromey
2024-03-11 10:27     ` Andrew Burgess
2024-03-22 17:25       ` Tom Tromey
2024-02-07 16:27 ` Christian Biesinger
2024-02-08 16:10   ` Andrew Burgess
2024-02-08 16:18     ` Christian Biesinger
2024-03-06 10:17 ` Andrew Burgess
2024-03-08 18:03   ` Tom Tromey [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=874jdgr47o.fsf@tromey.com \
    --to=tom@tromey.com \
    --cc=aburgess@redhat.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=gdb-patches@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox