From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15024 invoked by alias); 14 Dec 2010 09:27:16 -0000 Received: (qmail 15016 invoked by uid 22791); 14 Dec 2010 09:27:15 -0000 X-SWARE-Spam-Status: No, hits=-6.2 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 14 Dec 2010 09:27:09 +0000 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id oBE9Qs6s031288 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 14 Dec 2010 04:26:54 -0500 Received: from host0.dyn.jankratochvil.net (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id oBE9QntN026085 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Dec 2010 04:26:53 -0500 Received: from host0.dyn.jankratochvil.net (host0.dyn.jankratochvil.net [127.0.0.1]) by host0.dyn.jankratochvil.net (8.14.4/8.14.4) with ESMTP id oBE9QmuS020348; Tue, 14 Dec 2010 10:26:48 +0100 Received: (from jkratoch@localhost) by host0.dyn.jankratochvil.net (8.14.4/8.14.4/Submit) id oBE9Qjrs020338; Tue, 14 Dec 2010 10:26:45 +0100 Date: Tue, 14 Dec 2010 09:27:00 -0000 From: Jan Kratochvil To: Joel Brobecker Cc: Doug Evans , gdb-patches@sourceware.org, David Malcolm , Tom Tromey Subject: Re: [RFA] ignore PYTHONHOME environment variable. Message-ID: <20101214092645.GA20415@host0.dyn.jankratochvil.net> References: <1290474202-885-1-git-send-email-brobecker@adacore.com> <20101123030037.GA19962@host0.dyn.jankratochvil.net> <20101123163045.GA1737@host0.dyn.jankratochvil.net> <20101123173054.GW2634@adacore.com> <20101214071210.GQ2596@adacore.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20101214071210.GQ2596@adacore.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2010-12/txt/msg00220.txt.bz2 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: > > > 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