From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23765 invoked by alias); 12 Jun 2014 17:15:30 -0000 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 Received: (qmail 23755 invoked by uid 89); 12 Jun 2014 17:15:29 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.8 required=5.0 tests=AWL,BAYES_00,SPF_SOFTFAIL autolearn=no version=3.3.2 X-HELO: mtaout28.012.net.il Received: from mtaout28.012.net.il (HELO mtaout28.012.net.il) (80.179.55.184) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 12 Jun 2014 17:15:27 +0000 Received: from conversion-daemon.mtaout28.012.net.il by mtaout28.012.net.il (HyperSendmail v2007.08) id <0N7200C00FO6YQ00@mtaout28.012.net.il> for gdb-patches@sourceware.org; Thu, 12 Jun 2014 20:13:44 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout28.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0N7200CI0FUWFA10@mtaout28.012.net.il>; Thu, 12 Jun 2014 20:13:44 +0300 (IDT) Date: Thu, 12 Jun 2014 17:15:00 -0000 From: Eli Zaretskii Subject: Re: Building the current snapshot on Windows with Guile In-reply-to: <87ha3qlehr.fsf@gnu.org> To: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) Cc: xdje42@gmail.com, gdb-patches@sourceware.org Reply-to: Eli Zaretskii Message-id: <83sinaxd5s.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8BIT References: <83y4x614y6.fsf@gnu.org> <87ha3rocq3.fsf@gnu.org> <83k38nze3y.fsf@gnu.org> <87ha3qlehr.fsf@gnu.org> X-IsSubscribed: yes X-SW-Source: 2014-06/txt/msg00512.txt.bz2 > From: ludo@gnu.org (Ludovic Courtès) > Cc: xdje42@gmail.com, gdb-patches@sourceware.org > Date: Thu, 12 Jun 2014 10:27:12 +0200 > > > Apart of the issue with multi-ABI platforms, are there any other > > reasons for the *.go files to be non-portable? > > In Guile 2.0, .go files are not portable essentially because sizeof(SCM) > is the size of a pointer, and because numbers stored in .go files are in > native endianness. (Guile 2.2 uses ELF as its container format, with > similar issues.) Ouch! That's going to be a drag, IMO. Now I understand why there are no compiled *.go files in the Guile distribution (unlike with Emacs, for example). In that case, I guess it will be impossible to distribute precompiled scm files with the GDB tarball, per your suggestion. Or am I missing something? > > E.g., if they were compiled on a 64-bit Windows 7, will they work on a > > 32-bit Windows XP? > > No. > > > Does the answer depend on whether the Guile executable that compiled > > the *.scm files was a 64-bit or a 32-bit executable? > > No. I'm puzzled: a 32-bit program still produces 32-bit code and uses 32-bit pointers, even when it runs on a 64-bit machine. So why the second "No"? > > What about compiling on GNU/Linux and using on Windows, when the CPU > > is the same or from the same family? > > That works fine. Do the .go files use portable format for numbers? There's a potential issue because a 'long' on a 64-bit GNU/Linux system is a 64-bit quantity, while 64-bit Windows uses 32-bit 'long's. Could this be an issue? Thanks.