This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFA] ignore PYTHONHOME environment variable.


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]