Re: Building the current snapshot on Windows with Guile

[Eli Zaretskii <eliz at gnu dot org>]

> 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.