From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27455 invoked by alias); 29 Sep 2011 08:39:10 -0000 Received: (qmail 27338 invoked by uid 22791); 29 Sep 2011 08:39:08 -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-vw0-f41.google.com (HELO mail-vw0-f41.google.com) (209.85.212.41) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 29 Sep 2011 08:38:52 +0000 Received: by vws16 with SMTP id 16so304264vws.0 for ; Thu, 29 Sep 2011 01:38:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.65.226 with SMTP id a2mr10762524vdt.111.1317285531617; Thu, 29 Sep 2011 01:38:51 -0700 (PDT) Received: by 10.220.180.5 with HTTP; Thu, 29 Sep 2011 01:38:51 -0700 (PDT) In-Reply-To: <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> <83ty7verow.fsf@gnu.org> Date: Thu, 29 Sep 2011 08:54:00 -0000 Message-ID: Subject: Re: [RFC] Crash sourcing Python script on Windows From: Kai Tietz To: Eli Zaretskii Cc: Joel Brobecker , maillist-gdbpatches@barfooze.de, gdb-patches@sourceware.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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/msg00509.txt.bz2 2011/9/29 Eli Zaretskii : >> 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. =A0Which 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. The issue here is not the definition of the FILE type itself in this case. The problem is that python (if built with VC) uses different runtime-version (msvcr100.dll or lower), but mingw uses by well know reasons the msvcrt.dll. So by loading this python-DLL into a mingw-built executable, we have two different runtimes at the same time. So FILE * of one library not necessarily operates in the other library. By the way, the same issue can lead also for different C-runtime functions pretty funny results. Regards, Kai