Re: [PATCH] gdb: Allow more control over where to find python libraries

[Andrew Burgess <andrew.burgess@embecosm.com>]

* Simon Marchi <simark@simark.ca> [2020-02-07 12:58:46 -0500]:

> On 2020-02-06 11:46 a.m., Andrew Burgess wrote:
> > The motivation behind this commit is to make it easier to bundle the
> > Python libraries with GDB when linking GDB against a static
> > libpython, the Python libraries will be manually added into the GDB
> > installation tree, and GDB should be able to find them at run-time.
> > The installation tree will look like this:
> > 
> >   .
> >   |-- bin/
> >   |-- include/
> >   |-- lib/
> >   |   `-- python3.8/
> >   `-- share/
> > 
> > The benefit here is that the entire installation tree can be bundled
> > into a single archive and copied to another machine with a different
> > version of Python installed, and GDB will still work, including its
> > Python support.
> 
> For those who might be wondering, like me: isn't the goal of linking
> statically with the lib to avoid having an external library?  This
> patch actually deals with finding the .py files provided by the Python
> standard library, not the native code.  The native code is indeed
> linked statically inside the gdb executable.

Yes, this is it exactly. I will rewrite the commit message to say '.py
files' instead as that's much clearer.

Thanks,
Andrew



> 
> I won't pretend to understand in details what's happening with the Python
> detection in configure (I find it's quite messy), but I didn't spot anything
> wrong with your patch, and it seems to address a valid use case, so I'm not
> against it.
> 
> Simon