From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19390 invoked by alias); 30 May 2013 08:35:51 -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 19358 invoked by uid 89); 30 May 2013 08:35:45 -0000 X-Spam-SWARE-Status: No, score=-3.7 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,RCVD_IN_DNSWL_NONE,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.1 Received: from plane.gmane.org (HELO plane.gmane.org) (80.91.229.3) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Thu, 30 May 2013 08:35:44 +0000 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1UhyKj-0003Gr-Lt for gdb@sourceware.org; Thu, 30 May 2013 10:35:41 +0200 Received: from razumovsky.net ([82.68.48.14]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 30 May 2013 10:35:41 +0200 Received: from jules by razumovsky.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 30 May 2013 10:35:41 +0200 To: gdb@sourceware.org From: Julian Smith Subject: Re: Building current gdb on centos-5 Date: Thu, 30 May 2013 08:35:00 -0000 Message-ID: <20130530093531.6549fea0.jules@op59.net> References: <20130529215013.70904c7d.jules@op59.net> <51A708FA.1070404@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit In-Reply-To: <51A708FA.1070404@redhat.com> X-SW-Source: 2013-05/txt/msg00132.txt.bz2 On Thu, 30 May 2013 09:08:26 +0100 Pedro Alves wrote: > 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. Thanks. > > 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! Here it is, in /usr/include/python2.4/object.h: #define Py_DECREF(op) \ if (_Py_DEC_REFTOTAL _Py_REF_DEBUG_COMMA \ --(op)->ob_refcnt != 0) \ _Py_CHECK_REFCNT(op) \ else \ _Py_Dealloc((PyObject *)(op)) Thanks, - Julian -- http://op59.net/