Is python dependency detection acceptable?

[Tony Wang]

Hi, there

Recently I'm building gdb with python support, and I noticed that gdb
with python support will heavily depends on the python environment on
the build machine.

So if I give the gdb with python support to other PC, and the python
environment is different from my build machine, the gdb will fail to
launch. Basically, I think python support is not wanted by every user,
but it's a little bit confusing for toolchain maintainer to release
two version of gdb(with and without python). So is it possible to
detect in the gdb, whether the user python environment is ok?(Usually
user will have python, but the library path or version may cause the
gdb fail to launch). If the user do not have the python, then just
disable python function in gdb.

I've noticed a hack patch to do this before, it just test the pyinit
function in a new thread to see if the python environment is ready. Is
such a operation acceptable?

BR,
Tony

[Mike Frysinger]

Post by Tony Wang
Recently I'm building gdb with python support, and I noticed that gdb
with python support will heavily depends on the python environment on
the build machine.
So if I give the gdb with python support to other PC, and the python
environment is different from my build machine, the gdb will fail to
launch. Basically, I think python support is not wanted by every user,
but it's a little bit confusing for toolchain maintainer to release
two version of gdb(with and without python). So is it possible to
detect in the gdb, whether the user python environment is ok?(Usually
user will have python, but the library path or version may cause the
gdb fail to launch). If the user do not have the python, then just
disable python function in gdb.
I've noticed a hack patch to do this before, it just test the pyinit
function in a new thread to see if the python environment is ready. Is
such a operation acceptable?

this is how we addressed it in CrOS:
https://chromium.googlesource.com/chromiumos/third_party/gdb/+/b35e9f2915f319ed23e50d66c5d157370e113317%5E%21/

we had to do this for the same reason you describe -- we build gdb in one env
(Gentoo) and deploy it in another (Ubuntu), and the two have different pythons
available. python works fine in the original env and we want to keep it
viable, but we don't want gdb killing itself simply because python isn't
available.

hopefully Yunlian will submit the patch for official consideration at some
point :).
-mike