From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17256 invoked by alias); 12 Jun 2014 19:46:33 -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 17068 invoked by uid 89); 12 Jun 2014 19:46:31 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.2 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_SOFTFAIL autolearn=no version=3.3.2 X-HELO: hera.aquilenet.fr Received: from hera.aquilenet.fr (HELO hera.aquilenet.fr) (141.255.128.1) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 12 Jun 2014 19:46:29 +0000 Received: from localhost (localhost [127.0.0.1]) by hera.aquilenet.fr (Postfix) with ESMTP id C52292CD5; Thu, 12 Jun 2014 21:46:25 +0200 (CEST) Received: from hera.aquilenet.fr ([127.0.0.1]) by localhost (hera.aquilenet.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Up+nN7-onzgz; Thu, 12 Jun 2014 21:46:25 +0200 (CEST) Received: from pluto (reverse-83.fdn.fr [80.67.176.83]) by hera.aquilenet.fr (Postfix) with ESMTPSA id 3F4CC2C43; Thu, 12 Jun 2014 21:46:25 +0200 (CEST) From: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) To: Eli Zaretskii Cc: xdje42@gmail.com, gdb-patches@sourceware.org Subject: Re: Building the current snapshot on Windows with Guile References: <83y4x614y6.fsf@gnu.org> <87ha3rocq3.fsf@gnu.org> <83k38nze3y.fsf@gnu.org> <87ha3qlehr.fsf@gnu.org> <83sinaxd5s.fsf@gnu.org> X-URL: http://www.fdn.fr/~lcourtes/ X-Revolutionary-Date: 24 Prairial an 222 de la =?utf-8?Q?R=C3=A9volution?= X-PGP-Key-ID: 0xEA52ECF4 X-PGP-Key: http://www.fdn.fr/~lcourtes/ludovic.asc X-PGP-Fingerprint: 83C4 F8E5 10A3 3B4C 5BEA D15D 77DD 95E2 EA52 ECF4 X-OS: x86_64-unknown-linux-gnu Date: Thu, 12 Jun 2014 19:46:00 -0000 In-Reply-To: <83sinaxd5s.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 12 Jun 2014 20:15:11 +0300") Message-ID: <8738f9hpwv.fsf@gnu.org> User-Agent: Gnus/5.130009 (Ma Gnus v0.9) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-SW-Source: 2014-06/txt/msg00523.txt.bz2 Eli Zaretskii skribis: >> From: ludo@gnu.org (Ludovic Court=C3=A8s) >> Cc: xdje42@gmail.com, gdb-patches@sourceware.org >> Date: Thu, 12 Jun 2014 10:27:12 +0200 >>=20 >> > Apart of the issue with multi-ABI platforms, are there any other >> > reasons for the *.go files to be non-portable? >>=20 >> 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? I was not suggesting to distribute the .go files; rather, I was suggesting to add makefile rules to build them and install them. >> > E.g., if they were compiled on a 64-bit Windows 7, will they work on a >> > 32-bit Windows XP? >>=20 >> No. >>=20 >> > Does the answer depend on whether the Guile executable that compiled >> > the *.scm files was a 64-bit or a 32-bit executable? >>=20 >> 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"? Oh you=E2=80=99re right, sorry for the confusion. What matters is sizeof(S= CM). >> > What about compiling on GNU/Linux and using on Windows, when the CPU >> > is the same or from the same family? >>=20 >> That works fine. > > Do the .go files use portable format for numbers? Yes (info "(guile) Data Constructor Instructions"). > 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? Nope. The =E2=80=98make-intXX=E2=80=99 VM instructions are independent of = the C type definitions. Guile supports bignums and those can be also be stored safely in compiled files (info "(guile) Loading Instructions"). I hope this clarifies things. Ludo=E2=80=99.