From: "Ludovic Courtès" <ludo@gnu.org>
To: 44000@debbugs.gnu.org
Subject: bug#44000: Guile-Git cross-compiled to i586-pc-gnu gets bytestructures wrong
Date: Thu, 15 Oct 2020 00:25:54 +0200 [thread overview]
Message-ID: <87v9fccuml.fsf@inria.fr> (raw)
Hello!
You might have seen that ‘guix pull’ doesn’t work in your childhurd:
--8<---------------cut here---------------start------------->8---
Updating channel 'guix' from Git repository at 'https://git.savannah.gnu.org/git/guix.git'...
guix pull: error: Git error: invalid version 0 on git_proxy_options
--8<---------------cut here---------------end--------------->8---
This is due to an ABI breakage whereby the Guile-Git code
(cross-compiled from x86_64-linux) fills in the ‘fetch_opts’ member of
‘git_clone options’ offset by one word.
On closer inspection, the problem is:
--8<---------------cut here---------------start------------->8---
scheme@(git structs)> (bytestructure-descriptor-size (bs:struct `(("x" ,(bs:pointer uint8)) ("y" ,size_t))))
$20 = 12
scheme@(git structs)> %host-type
$21 = "i586-pc-gnu"
--8<---------------cut here---------------end--------------->8---
Compare with the correct answer:
--8<---------------cut here---------------start------------->8---
$ guix environment --ad-hoc -C -s i686-linux guile guile-bytestructures -- guile
[...]
scheme@(guile-user)> ,use(bytestructures guile)
scheme@(guile-user)> %host-type
$1 = "i686-unknown-linux-gnu"
scheme@(guile-user)> (bytestructure-descriptor-size (bs:struct `(("x" ,(bs:pointer uint8))("y" ,size_t))))
$2 = 8
--8<---------------cut here---------------end--------------->8---
More specifically, the size of ‘size_t’ is wrong, but pointer size is
right:
--8<---------------cut here---------------start------------->8---
scheme@(git structs)> (bytestructure-descriptor-size size_t)
$27 = 8
scheme@(git structs)> (bytestructure-descriptor-size uintptr_t )
$28 = 8
scheme@(git structs)> (bytestructure-descriptor-size (bs:pointer uint8))
$29 = 4
--8<---------------cut here---------------end--------------->8---
‘numeric.scm’ in bytestructures reads:
--8<---------------cut here---------------start------------->8---
(define arch32bit? (cond-expand
(lp32 #t)
(ilp32 #t)
(else #f)))
;; …
(define uintptr_t (if arch32bit?
uint32
uint64))
(define size_t uintptr_t)
--8<---------------cut here---------------end--------------->8---
But (bytestructures guile numeric-data-model) has this:
--8<---------------cut here---------------start------------->8---
(define data-model
(if (= 4 (sizeof '*))
(if (= 2 (sizeof int))
'lp32
'ilp32)
(cond
((= 8 (sizeof int)) 'ilp64)
((= 4 (sizeof long)) 'llp64)
(else 'lp64))))
(cond-expand-provide
(current-module)
(list architecture data-model))
--8<---------------cut here---------------end--------------->8---
The problem is that the ‘cond-expand’ used to define ‘arch32bit?’ is a
expansion-time thing when (cross-)building Bytestructures itself, so
it’s incorrect from cross-building from 64-bit to 32-bit.
I believe that changing it to:
(define arch32bit? (memq data-model '(ilp32 lp32)))
would fix it because then the test would happen at run time.
(Note that Guile-Git uses only the procedural layer of Bytestructures.
The syntactic layer is likely not cross-compilation-capable for similar
reasons.)
To be continued…
Thanks,
Ludo’.
next reply other threads:[~2020-10-14 22:27 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-14 22:25 Ludovic Courtès [this message]
2020-10-15 7:42 ` bug#44000: Guile-Git cross-compiled to i586-pc-gnu gets bytestructures wrong Ludovic Courtès
2020-10-15 8:09 ` Ludovic Courtès
2020-10-15 8:48 ` Mathieu Othacehe
2020-10-15 10:06 ` Jan Nieuwenhuizen
2020-10-16 15:58 ` Taylan Kammer
2020-10-17 17:44 ` Taylan Kammer
2020-10-19 8:23 ` Ludovic Courtès
2020-10-22 18:47 ` Taylan Kammer
2020-11-16 16:10 ` Ludovic Courtès
2020-11-16 17:07 ` Taylan Kammer
2020-11-16 17:37 ` Ludovic Courtès
2020-11-16 22:01 ` Ludovic Courtès
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87v9fccuml.fsf@inria.fr \
--to=ludo@gnu.org \
--cc=44000@debbugs.gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/guix.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.