Subject: Guile-Git cross-compiled to i586-pc-gnu gets bytestructures wrong

From: Ludovic Courtès <[email-masked]>
Date: Thu, 15 Oct 2020 00:25:54 +0200

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