This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Building the current snapshot on Windows with Guile


Eli Zaretskii <eliz@gnu.org> skribis:

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

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?
>> 
>> 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"?

Oh youâre right, sorry for the confusion.  What matters is sizeof(SCM).

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

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 âmake-intXXâ 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â.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]