This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: GDB with python support: which version of Python?
- From: Pedro Alves <palves at redhat dot com>
- To: Joel Brobecker <brobecker at adacore dot com>
- Cc: Paul Smith <psmith at gnu dot org>, gdb at sourceware dot org
- Date: Fri, 31 May 2013 11:18:41 +0100
- Subject: Re: GDB with python support: which version of Python?
- References: <1369951459 dot 3295 dot 229 dot camel at pdsdesk> <20130531044006 dot GB4395 at adacore dot com> <1369979331 dot 4119 dot 19 dot camel at homebase> <20130531060031 dot GC4395 at adacore dot com>
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