From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13673 invoked by alias); 31 May 2013 05:49:11 -0000 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 Received: (qmail 13655 invoked by uid 89); 31 May 2013 05:49:08 -0000 X-Spam-SWARE-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,RCVD_IN_HOSTKARMA_YE,RCVD_IN_NIX_SPAM,SPF_SOFTFAIL autolearn=no version=3.3.1 Received: from oproxy12-pub.bluehost.com (HELO oproxy12-pub.bluehost.com) (50.87.16.10) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with SMTP; Fri, 31 May 2013 05:48:54 +0000 Received: (qmail 30023 invoked by uid 0); 31 May 2013 05:48:53 -0000 Received: from unknown (HELO box531.bluehost.com) (74.220.219.131) by oproxy12.bluehost.com with SMTP; 31 May 2013 05:48:53 -0000 Received: from [146.115.71.23] (port=52834 helo=[172.31.1.206]) by box531.bluehost.com with esmtpsa (SSLv3:CAMELLIA256-SHA:256) (Exim 4.80) (envelope-from ) id 1UiICq-0005mw-Vp; Thu, 30 May 2013 23:48:53 -0600 Message-ID: <1369979331.4119.19.camel@homebase> Subject: Re: GDB with python support: which version of Python? From: Paul Smith Reply-To: psmith@gnu.org To: Joel Brobecker Cc: gdb@sourceware.org Date: Fri, 31 May 2013 05:49:00 -0000 In-Reply-To: <20130531044006.GB4395@adacore.com> References: <1369951459.3295.229.camel@pdsdesk> <20130531044006.GB4395@adacore.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Mime-Version: 1.0 X-Identified-User: {678:box531.bluehost.com:madscie1:mad-scientist.us} {sentby:smtp auth 146.115.71.23 authed with paul@mad-scientist.us} X-SW-Source: 2013-05/txt/msg00141.txt.bz2 On Fri, 2013-05-31 at 08:40 +0400, Joel Brobecker wrote: > > I'm trying to build a portable version of GDB, with Python support, that > > I can use on many different (GNU/Linux) systems. It's frustrating > > because Python versions are all over the place: every distro you use, it > > seems like, has a different not-completely-compatible version. > > Forcing static libraries might work on GNU/Linux systems, but > we've found it to be unworkable in general. Interesting; what kinds of problems did you have? > Here is what we do at AdaCore: we build and install GDB inside > GDB's prefix, I assume you mean build and install _Python_ inside GDB's prefix? > and use that to configure GDB. You can then ship > the entire GDB install, including Python. As long as the Python > path is inside the GDB prefix, GDB should be locating the Python > install fine (unless the user has the PYTHONHOME environment > variable set, in which case I believe it overrides GDB's default > behavior). But don't you have to set LD_LIBRARY_PATH or something to find the libpython.so, if you link dynamically? I guess this could be done with a gdb wrapper script of some kind. Or, is the installation not relocatable (it must always be installed in the same place)? Our installation needs to be relocatable. This is an interesting idea, though, I'll look into it.