From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2042 invoked by alias); 30 May 2013 08:08:40 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 2028 invoked by uid 89); 30 May 2013 08:08:39 -0000 X-Spam-SWARE-Status: No, score=-8.1 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.1 Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Thu, 30 May 2013 08:08:39 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r4U88SuT021990 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 30 May 2013 04:08:28 -0400 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id r4U88Qoo030109; Thu, 30 May 2013 04:08:27 -0400 Message-ID: <51A708FA.1070404@redhat.com> Date: Thu, 30 May 2013 08:08:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130311 Thunderbird/17.0.4 MIME-Version: 1.0 To: Julian Smith CC: gdb@sourceware.org Subject: Re: Building current gdb on centos-5 References: <20130529215013.70904c7d.jules@op59.net> In-Reply-To: <20130529215013.70904c7d.jules@op59.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-SW-Source: 2013-05/txt/msg00130.txt.bz2 On 05/29/2013 09:50 PM, Julian Smith wrote: > Is the latest gdb in cvs, expected to build on centos-5 ? It should, but looks like I broke it. > I'm seeing this build failure: > > ... > gcc -g -O2 -I. -I. -I./common -I./config -DLOCALEDIR="\"/usr/local/share/locale\"" -DHAVE_CONFIG_H -I./../include/opcode -I./../opcodes/.. -I./../readline/.. -I../bfd -I./../bfd -I./../include -I../libdecnumber -I./../libdecnumber -I./gn > ulib/import -Ibuild-gnulib/import -DTUI=1 -I/usr/include/python2.4 -I/usr/include/python2.4 -Wall -Wdeclaration-after-statement -Wpointer-arith -Wpointer-sign -Wno-unused -Wunused-value -Wunused-function -Wno-switch -Wno-char-subscripts > -Wmissing-prototypes -Wdeclaration-after-statement -Wformat-nonliteral -c -o mi-main.o -MT mi-main.o -MMD -MP -MF .deps/mi-main.Tpo ./mi/mi-main.c > In file included from ./mi/mi-main.c:56: > ./python/python-internal.h: In function 'gdb_Py_DECREF': > ./python/python-internal.h:179: warning: dereferencing 'void *' pointer > ./python/python-internal.h:179: error: request for member 'ob_refcnt' in something not a structure or union Thanks. gdb_Py_DECREF is a recent addition: /* Python 2.6 did not wrap Py_DECREF in 'do {...} while (0)', leading to 'suggest explicit braces to avoid ambiguous ‘else’' gcc errors. Wrap it ourselves, so that callers don't need to care. */ static inline void gdb_Py_DECREF (void *op) /* ARI: editCase function */ { Py_DECREF (op); } Making that: - Py_DECREF (op); + Py_DECREF ((PyObject*) op); should fix this. I'll push a fix. On my system's Python 2.7, Py_DECREF always casts its argument to (PyObject*), so it didn't seem necessary to cast it ourselves: #define Py_DECREF(op) \ do { \ if (_Py_DEC_REFTOTAL _Py_REF_DEBUG_COMMA \ --((PyObject*)(op))->ob_refcnt != 0) \ _Py_CHECK_REFCNT(op) \ else \ _Py_Dealloc((PyObject *)(op)); \ } while (0) > My centos-5 has python-2.4 (python-devel.i386 2.4.3-24.el5). For the archives, could you please paste what Py_DECREF looks like in 2.4? Thanks! -- Pedro Alves