unofficial mirror of bug-guix@gnu.org 
 help / color / mirror / code / Atom feed
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’.




             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

  List information: https://guix.gnu.org/

* 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 public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).