GDB with python support: which version of Python?

GDB with python support: which version of Python?

[Paul Smith]

Hi all;

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.

Plus, I can't find any straightforward way to build GDB with Python
linked statically to avoid local .so version problems.  Seems GDB
configure doesn't really support this.  I'm thinking of pulling a Python
install without any .so to force static linking.  Have others tried
this?

I see from the README that the "oldest version of Python supported by
GDB is 2.4".  Is there a _recommended_ version of Python?  2.7?  3.x?
Something else?


Thanks!

Re: GDB with python support: which version of Python?

[Paul_Koning]

On May 30, 2013, at 6:04 PM, Paul Smith wrote:

> Hi all;
> 
> 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.
> 
> Plus, I can't find any straightforward way to build GDB with Python
> linked statically to avoid local .so version problems.  Seems GDB
> configure doesn't really support this.  I'm thinking of pulling a Python
> install without any .so to force static linking.  Have others tried
> this?
> 
> I see from the README that the "oldest version of Python supported by
> GDB is 2.4".  Is there a _recommended_ version of Python?  2.7?  3.x?
> Something else?

My personal favorite is 3.latest, but for those who want Python 2, I'd say 2.latest (i.e., 2.7).  But it's really more a matter of what you have installed.  If you can most easily install some other version, or you have other libraries that need a particular Python version, then that would decide things.

I've built gdb for pretty much all the 2.x and 3.x versions supported; it's all easy.

	paul

Re: GDB with python support: which version of Python?

[Joel Brobecker]

> 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.

Here is what we do at AdaCore: we build and install GDB 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).

-- 
Joel

Re: GDB with python support: which version of Python?

[Paul Smith]

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.

Re: GDB with python support: which version of Python?

[Joel Brobecker]

> > 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?

Actually, I take back what I said, I was completely confused.
Sorry! We are indeed using static libraries as far as I can
tell. The relocation is still necessary, because Python needs
to be able to find its runtime.

I had this idea at some point of having GDB dlopen libpython,
which case it'd be possible to ship shared Python libraries
without having to worry about LD_LIBRARY_PATH. But our experience
with VxWorks (WTX) libraries, where we do this, and the fact
that we have been able to use static libraries, led me to put
this idea on the side for now.

> > 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?

Yes. I clearly needed more coffee this morning before answering :-/.

-- 
Joel

Re: GDB with python support: which version of Python?

[Pedro Alves]

On 05/31/2013 07:00 AM, Joel Brobecker wrote:
>>> 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?
> 
> Actually, I take back what I said, I was completely confused.
> Sorry! We are indeed using static libraries as far as I can
> tell. The relocation is still necessary, because Python needs
> to be able to find its runtime.
> 
> I had this idea at some point of having GDB dlopen libpython,
> which case it'd be possible to ship shared Python libraries
> without having to worry about LD_LIBRARY_PATH. But our experience
> with VxWorks (WTX) libraries, where we do this, and the fact
> that we have been able to use static libraries, led me to put
> this idea on the side for now.
> 
>>> 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?
> 
> Yes. I clearly needed more coffee this morning before answering :-/.
> 

IMO, it'd be super nice if we had a page in the wiki describing
this use case, and the mechanism people use to solve it.
Seems like everyone who builds relocatable gdbs meant to be
installed in a multitude of systems (as opposed to a system/distro
gdb), ends up needing to know this.

-- 
Pedro Alves

Re: GDB with python support: which version of Python?

[Joseph S. Myers]

On Thu, 30 May 2013, Paul Smith wrote:

> Hi all;
> 
> 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.
> 
> Plus, I can't find any straightforward way to build GDB with Python
> linked statically to avoid local .so version problems.  Seems GDB
> configure doesn't really support this.  I'm thinking of pulling a Python
> install without any .so to force static linking.  Have others tried
> this?

You can link with a .so copy of Python shipped with the GDB installation 
using -Wl,-rpath,$ORIGIN.  Unfortunately multiple levels of shell and 
makefile interpretation make passing that '$' down a pain; at Mentor we 
have a shell variable setting

flags='-Wl,-rpath,'\''\\\$$\$$\\\$$\$$ORIGIN'\''/../'"$pypath"

for this purpose, but the exact levels of quotation required may depend on 
exactly how you pass the linker options when configuring GDB.  See 
<http://sourceware.org/ml/binutils/2009-10/msg00257.html>.

-- 
Joseph S. Myers
joseph@codesourcery.com