Re: Make GDB build with python 2.4 again.

[Pedro Alves <pedro@codesourcery.com>]

On Sunday 19 October 2008 23:46:58, Paul Pluzhnikov wrote:
> On Sun, Oct 19, 2008 at 1:18 PM, Pedro Alves <pedro@codesourcery.com> wrote:
> 
> > I'm checking in the attached fix.  I get 95 expected passes with
> > both 2.4 and 2.5.
> 
> Meanwhile, on 'archer-tromey-python':

Sorry, but if you know something is broken in code that's in the FSF
tree, you should post a patch there.  You can't expect me to track what's
going on the archer branches.

> 
> $ git show 083493c09e01a8e67057b890689883ddbd6bc830
> commit 083493c09e01a8e67057b890689883ddbd6bc830
> Author: Paul Pluzhnikov <ppluzhnikov@google.com>
> Date:   Mon Oct 13 15:54:49 2008 -0700
> 
>     2008-10-13  Paul Pluzhnikov  <ppluzhnikov@google.com>
> 
>         * python/python-internal.h: Fix 64-bit compilation with python2.4
> 
> diff --git a/gdb/python/python-internal.h b/gdb/python/python-internal.h
> index 5896907..207d3e4 100644
> --- a/gdb/python/python-internal.h
> +++ b/gdb/python/python-internal.h
> @@ -33,8 +33,11 @@
> 
>  #if HAVE_LIBPYTHON2_4
>  #include "python2.4/Python.h"
> -/* Py_ssize_t is not defined until 2.5.  */
> -typedef Py_intptr_t Py_ssize_t;
> +/* Py_ssize_t is not defined until 2.5.
> +   Logical type for Py_ssize_t is Py_intptr_t, but that fails in 64-bit
> +   compilation due to several apparent mistakes in python2.4 API, so we
> +   use 'int' instead.  */
> +typedef int Py_ssize_t;
>  #elif HAVE_LIBPYTHON2_5
>  #include "python2.5/Python.h"
>  #elif HAVE_LIBPYTHON2_6
>
> 
> Note that in current gdb/python sources, additional changes
> are required for python2.4 if Py_ssize_t isn't fixed as above ...
> 

That looks strange, since ssize_t isn't usually the same size
of int.  Well, if this works for you, and you think you aren't
going to trip on that further on, then by all means, post a patch
at gdb-patches.  In the mean time, every one else can continue
building FSF GDB.

> > 2008-10-19  Pedro Alves  <pedro@codesourcery.com>
> >
> >        * python/python-value.c (value_object_methods)
> >        (value_object_as_number, value_object_as_mapping): Move to bottom
> >        of file.
> 
> Why?

To avoid all the forward references, so that we don't have to change
two places whenever an interface changes, or things like these happen.

-- 
Pedro Alves