Re: Python enabled gdb on Windows and relocation

[Doug Evans <dje@google.com>]

On Sun, May 15, 2011 at 6:26 AM, Ruben Van Boxem
<vanboxem.ruben@gmail.com> wrote:
> Wow, I think I have a partial solution. Delving into the Python docs,
> for example here:
> http://docs.python.org/using/windows.html#finding-modules, you can see
> that PYTHONPATH is used first, then the Windows registry, then
> PYTHONHOME, then some default relative paths. I placed the python
> scripts all in the directory structure like so:
>
> /bin/gdb
> /bin/Lib/<python scripts>
> /bin/python27.dll
>
> This works, even without any manual PYTHONPATH intervention. Problem
> is though, that as soon as someone has a PYTHONPATH environment
> variable from a (incompatible) Python installation (think different
> bitness or version 3.x instead of 2.7.1), I cannot predict what will
> go wrong. This problem originates in Python's way of filling in the
> search path (sys.path). A true solution in the GDB case to prevent
> this collision of an incompatible PYTHONPATH would be that GDB sets an
> internal PYTHONPATH as directed by configure, uses that to load its
> Python internals, and allows the GDB child processes (apps being
> debugged) to use the environment PYTHONPATH. For now, I have a
> functional installation, but it will break as soon as someone installs
> Python on their system.

What if the user *wants* gdb's python to use $PYTHONPATH from his/her
environment?
To handle *this* case, *and* the case of an incompatible python
installation using $PYTHONPATH, there is the $GDB_PYTHONPATH proposal
(see earlier email for details).  It feels problematic to decide at
configure time whether there will or will not be an incompatible
python at runtime.

[I realize you have subsequent messages.
Just replying in sequence.]