From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16128 invoked by alias); 28 Jul 2011 16:11:41 -0000 Received: (qmail 16106 invoked by uid 22791); 28 Jul 2011 16:11:36 -0000 X-SWARE-Spam-Status: No, hits=-1.8 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW X-Spam-Check-By: sourceware.org Received: from mail-qy0-f169.google.com (HELO mail-qy0-f169.google.com) (209.85.216.169) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 28 Jul 2011 16:11:21 +0000 Received: by qyk32 with SMTP id 32so3537556qyk.0 for ; Thu, 28 Jul 2011 09:11:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.176.145 with SMTP id be17mr177687qab.62.1311869480483; Thu, 28 Jul 2011 09:11:20 -0700 (PDT) Received: by 10.229.99.137 with HTTP; Thu, 28 Jul 2011 09:11:20 -0700 (PDT) In-Reply-To: References: <20110728151915.GU1988@adacore.com> Date: Thu, 28 Jul 2011 16:11:00 -0000 Message-ID: Subject: Re: py-breakpoint.c fails to compile with MinGW GCC From: Kai Tietz To: Tom Tromey Cc: Joel Brobecker , pmuldoon@redhat.com, Eli Zaretskii , gdb@sourceware.org Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes 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 X-SW-Source: 2011-07/txt/msg00113.txt.bz2 2011/7/28 Tom Tromey : > Joel> It does compile for me too. Could be a compiler age issue? > > I asked Kai and that is what he thinks. > > The Python docs don't say much: > > =A0 =A0We=92d like to just assign this to the tp_new slot, but we can=92t= , for > =A0 =A0portability sake, On some platforms or compilers, we can=92t stati= cally > =A0 =A0initialize a structure member with a function defined in another C > =A0 =A0module, so, instead, we=92ll assign the tp_new slot in the module > =A0 =A0initialization function just before calling PyType_Ready(): > > See http://docs.python.org/extending/newtypes.html > > Joel> Just wondering out loud - if we were to use a C++ compiler, would > Joel> it allow us to use non-static initializers like in this case? > Joel> I'm under the impression that C++ provides elaboration, so > Joel> non-static initialization should be do-able... > > That would work; and while I want to do this, I think it is simpler to > just fix the initializations. =A0Or, just require people to use a newer > GCC; 3.4 is 5 years old at this point. > > Tom I looked a bit more in detail on this issue and indeed it is a compiler age issue. Newer compilers with pseudo-relocation support are able to handle DLL-imported symbols in assignments for global/static variables. This is for older gcc versions (and indeed 3.4 is pretty old one) not possi= ble. Regards, Kai