Specify python2 or python3 as Python program name

Message ID 1463003507-13094-1-git-send-email-nchen@mozilla.com
State New, archived
Headers

Commit Message

Jim Chen May 11, 2016, 9:51 p.m. UTC
  Hi,

When initializing Python, GDB hard codes the Python program name to
$prefix/bin/python, where $prefix is /usr for example. On some
platforms, /usr/bin/python points to python3. So what happens is, even
if GDB is built with python2 support, GDB ends up setting the Python
program name to point to python3, causing a mismatch. I think it's
better to deliberately specify python2 or python3.

Patch tested on x86_64-linux.

gdb:

2016-05-05  Jim Chen <nchen@mozilla.com>

	* python/python.c (_initialize_python): Specify python2 or python3
	when initializing the Python program name.
---
 gdb/python/python.c | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)
  

Comments

Eli Zaretskii May 12, 2016, 5:53 a.m. UTC | #1
> From: Jim Chen <nchen@mozilla.com>
> Cc: Jim Chen <nchen@mozilla.com>
> Date: Wed, 11 May 2016 17:51:46 -0400
> 
> When initializing Python, GDB hard codes the Python program name to
> $prefix/bin/python, where $prefix is /usr for example. On some
> platforms, /usr/bin/python points to python3. So what happens is, even
> if GDB is built with python2 support, GDB ends up setting the Python
> program name to point to python3, causing a mismatch. I think it's
> better to deliberately specify python2 or python3.

I have Python 2.x installed, but there's no "python2" executable
anywhere in sight, only a "python" executable.  Does this patch mean
GDB will no longer be able to invoke Python on my system?

Thanks.
  
Yao Qi May 12, 2016, 12:50 p.m. UTC | #2
Jim Chen <nchen@mozilla.com> writes:

> When initializing Python, GDB hard codes the Python program name to
> $prefix/bin/python, where $prefix is /usr for example. On some
> platforms, /usr/bin/python points to python3. So what happens is, even
> if GDB is built with python2 support, GDB ends up setting the Python
> program name to point to python3, causing a mismatch. I think it's

I agree that is a problem ...

> better to deliberately specify python2 or python3.

... but I don't think your patch is the right fix.  What we can do in
GDB is probably emit an error if the $prefix/bin/python is incompatible
to the python we build gdb against.
  

Patch

diff --git a/gdb/python/python.c b/gdb/python/python.c
index c706644..4e80951 100644
--- a/gdb/python/python.c
+++ b/gdb/python/python.c
@@ -1701,17 +1701,23 @@  message == an error message without a stack will be printed."),
 #ifdef WITH_PYTHON_PATH
   /* Work around problem where python gets confused about where it is,
      and then can't find its libraries, etc.
      NOTE: Python assumes the following layout:
      /foo/bin/python
      /foo/lib/pythonX.Y/...
      This must be done before calling Py_Initialize.  */
   progname = concat (ldirname (python_libdir), SLASH_STRING, "bin",
-		     SLASH_STRING, "python", (char *) NULL);
+		     SLASH_STRING,
+#ifdef IS_PY3K
+		     "python3",
+#else
+		     "python2",
+#endif
+		     (char *) NULL);
 #ifdef IS_PY3K
   oldloc = xstrdup (setlocale (LC_ALL, NULL));
   setlocale (LC_ALL, "");
   progsize = strlen (progname);
   progname_copy = (wchar_t *) PyMem_Malloc ((progsize + 1) * sizeof (wchar_t));
   if (!progname_copy)
     {
       xfree (oldloc);