From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11132 invoked by alias); 17 May 2011 20:36:16 -0000 Received: (qmail 10999 invoked by uid 22791); 17 May 2011 20:36:15 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from smtp-out.google.com (HELO smtp-out.google.com) (216.239.44.51) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 17 May 2011 20:36:00 +0000 Received: from kpbe14.cbf.corp.google.com (kpbe14.cbf.corp.google.com [172.25.105.78]) by smtp-out.google.com with ESMTP id p4HKZdOl031547 for ; Tue, 17 May 2011 13:35:49 -0700 Received: from gwaa18 (gwaa18.prod.google.com [10.200.27.18]) by kpbe14.cbf.corp.google.com with ESMTP id p4HKZSL9022001 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 17 May 2011 13:35:28 -0700 Received: by gwaa18 with SMTP id a18so412820gwa.33 for ; Tue, 17 May 2011 13:35:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.91.198.23 with SMTP id a23mr846233agq.45.1305664527826; Tue, 17 May 2011 13:35:27 -0700 (PDT) Received: by 10.90.72.6 with HTTP; Tue, 17 May 2011 13:35:27 -0700 (PDT) In-Reply-To: References: Date: Tue, 17 May 2011 20:36:00 -0000 Message-ID: Subject: Re: Python enabled gdb on Windows and relocation From: Doug Evans To: vanboxem.ruben@gmail.com Cc: gdb@sourceware.org, python-list@python.org Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2011-05/txt/msg00082.txt.bz2 On Sun, May 15, 2011 at 6:26 AM, Ruben Van Boxem 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/ > /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.]