Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.python > #5610 > unrolled thread
| Started by | Doug Evans <dje@google.com> |
|---|---|
| First post | 2011-05-17 13:35 -0700 |
| Last post | 2011-05-17 13:35 -0700 |
| Articles | 1 — 1 participant |
Back to article view | Back to comp.lang.python
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
Re: Python enabled gdb on Windows and relocation Doug Evans <dje@google.com> - 2011-05-17 13:35 -0700
| From | Doug Evans <dje@google.com> |
|---|---|
| Date | 2011-05-17 13:35 -0700 |
| Subject | Re: Python enabled gdb on Windows and relocation |
| Message-ID | <mailman.1710.1305664546.9059.python-list@python.org> |
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.]
Back to top | Article view | comp.lang.python
csiph-web