GNU bug report logs -
#44000
Guile-Git cross-compiled to i586-pc-gnu gets bytestructures wrong
Previous Next
Full log
View this message in rfc822 format
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’.
This bug report was last modified 4 years and 215 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.