From: Jan Kratochvil <jan.kratochvil@redhat.com>
To: Joel Brobecker <brobecker@adacore.com>
Cc: Doug Evans <dje@google.com>,
gdb-patches@sourceware.org,
David Malcolm <dmalcolm@redhat.com>,
Tom Tromey <tromey@redhat.com>
Subject: Re: [RFA] ignore PYTHONHOME environment variable.
Date: Tue, 14 Dec 2010 09:27:00 -0000 [thread overview]
Message-ID: <20101214092645.GA20415@host0.dyn.jankratochvil.net> (raw)
In-Reply-To: <20101214071210.GQ2596@adacore.com>
On Tue, 14 Dec 2010 08:12:10 +0100, Joel Brobecker wrote:
> On Tue, Nov 23, 2010 at 09:30:54AM -0800, Joel Brobecker wrote:
> > > <jan.kratochvil@redhat.com> wrote:
> > > > But PYTHONHOME=$HOME for some user overrides of system Python would
> > > > no longer work. Â What would $PYTHONHOME otherwise be useful for?
> > >
> > > OTOH what if one wanted to debug a python with a different PYTHONHOME?
> > > GDB_PYTHONHOME? [not my idea, but seems reasonable]
> >
> > I think you indeed need something like that. I don't think we can trust
> > PYTHONHOME, because it might point to something that's incompatible.
>
> Jan: Does your objection still stand, or are you satisfied if we add
> a GDB_PYTHONHOME environment variable to control the Python home?
GDB_PYTHONHOME may exist and it can override any other settings, why not.
Still $PYTHONHOME should apply for GDB, the same way as it applies for
any other package. It is also the reason it exists. One may want to override
system Python installation in $HOME, with proper $LD_LIBRARY_PATH and
$PYTHONHOME I hope it should work well, as it works for other software.
Your proposed way the user would have to troubleshoot (s)he needs to set also
$GDB_PYTHONHOME, besides $PYTHONHOME.
On Tue, 23 Nov 2010 18:30:54 +0100, Joel Brobecker wrote:
# GDB_PYTHONHOME is something that got suggested by at least 2 people
# (someone at AdaCore also suggested it a while back).
How many OS distributors have suggested it? It is against the fundamental
distro policies. Many reasons why bundling is broken are at:
http://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries
> > But I think I would prefer something like this:
> >
> > if "GDB_PYTHONHOME" is defined
> > Py_SetPythonHome (getenv ("GDB_PYTHONHOME"));
> > #ifdef WITH_PYTHON_PATH
> > else
> > /* We override any value that the PYTHONHOME might have, as we want
> > to make sure that we use the Python library that comes with GDB. */
> > Py_SetPythonHome (ldirname (python_libdir));
> > #endif
> >
> > The latter makes GDB_PYTHONHOME always active, regardless of how
> > GDB was linked against Python.
This is a classical example of a vendor distribution patch which is not
expected to be present upstream. Still I can override these downstream; just
I believe upstream should not contain any sych directory hacks.
If you want it upstream why to just make it disabled during default
./configure? PYTHON_PATH_RELOCATABLE cannot be used as a conditional, during
--prefix=/usr with system Python one gets:
#define GDB_DATADIR_RELOCATABLE 1
#define PYTHONDIR "/usr/share/gdb/python"
#define PYTHON_PATH_RELOCATABLE 1
#define WITH_PYTHON_PATH "/usr"
Which also seems broken, though - why should system GDB use Python directories
depending on where the gdb binary is located? I apparently missed the patch.
I would propose some extra new configure option to both enable
PYTHON_PATH_RELOCATABLE only in such case and also to possibly disable
respecting $PYTHONHOME.
Regards,
Jan
next prev parent reply other threads:[~2010-12-14 9:27 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-11-23 1:03 Joel Brobecker
2010-11-23 3:01 ` Jan Kratochvil
2010-11-23 9:29 ` Doug Evans
2010-11-23 16:31 ` Jan Kratochvil
2010-11-23 16:57 ` Doug Evans
2010-11-23 17:31 ` Joel Brobecker
2010-12-14 7:12 ` Joel Brobecker
2010-12-14 9:27 ` Jan Kratochvil [this message]
2010-12-14 10:33 ` Joel Brobecker
2011-01-13 22:57 ` Joel Brobecker
2011-01-15 9:17 ` Doug Evans
2011-01-15 11:26 ` Jan Kratochvil
2011-01-17 10:36 ` Joel Brobecker
2012-05-18 19:34 ` Jan Kratochvil
2012-05-28 14:41 ` Joel Brobecker
2012-05-28 17:30 ` Jan Kratochvil
2012-05-29 14:54 ` Joel Brobecker
2012-05-29 15:57 ` Jan Kratochvil
2012-05-30 14:37 ` Jan Kratochvil
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=20101214092645.GA20415@host0.dyn.jankratochvil.net \
--to=jan.kratochvil@redhat.com \
--cc=brobecker@adacore.com \
--cc=dje@google.com \
--cc=dmalcolm@redhat.com \
--cc=gdb-patches@sourceware.org \
--cc=tromey@redhat.com \
/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