From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31602 invoked by alias); 29 Sep 2011 07:26:24 -0000 Received: (qmail 31586 invoked by uid 22791); 29 Sep 2011 07:26:22 -0000 X-SWARE-Spam-Status: No, hits=-1.3 required=5.0 tests=AWL,BAYES_00,SPF_SOFTFAIL X-Spam-Check-By: sourceware.org Received: from mtaout20.012.net.il (HELO mtaout20.012.net.il) (80.179.55.166) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 29 Sep 2011 07:26:08 +0000 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0LS900100WFWJ200@a-mtaout20.012.net.il> for gdb-patches@sourceware.org; Thu, 29 Sep 2011 10:25:02 +0300 (IDT) Received: from HOME-C4E4A596F7 ([84.228.8.215]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0LS9001UHWLPER40@a-mtaout20.012.net.il>; Thu, 29 Sep 2011 10:25:02 +0300 (IDT) Date: Thu, 29 Sep 2011 07:30:00 -0000 From: Eli Zaretskii Subject: Re: [RFC] Crash sourcing Python script on Windows In-reply-to: <20110929040634.GD19246@adacore.com> To: Joel Brobecker Cc: maillist-gdbpatches@barfooze.de, gdb-patches@sourceware.org Reply-to: Eli Zaretskii Message-id: <83ty7verow.fsf@gnu.org> References: <1317251996-12146-1-git-send-email-brobecker@adacore.com> <09787EF419216C41A903FD14EE5506DD03098D555B@AUSX7MCPC103.AMER.DELL.COM> <4E83D440.6000702@barfooze.de> <20110929040634.GD19246@adacore.com> X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2011-09/txt/msg00505.txt.bz2 > Date: Wed, 28 Sep 2011 21:06:34 -0700 > From: Joel Brobecker > Cc: gdb-patches@sourceware.org > > It could be something simpler than that. Python was built on one > system, using an unknown build environment. when then use that > library to link it against some code on a version of Windows that > is most likely different, with a compiler that is also most likely > different. If each compiler used a libc where the definition of > that type is different, then we have an incompatibility. That's true, but just looking at the definitions of the FILE object in both MS and MinGW headers, I can't see any differences. Which is quite expected: if it were not so, MinGW programs couldn't call APIs that accept FILE objects, like `fopen', since the implementation of `fopen' is in the Microsoft runtime DLLs, which was compiled by the Microsoft compiler, the same one used to build Python DLLs for Windows. So it would be good to know the details of what led you to the conclusion that the FILE object was incompatible between GDB and Python DLL.