GNU bug report logs - #54292
Commit e8518c43 breaks guix pull on i686

Previous Next

Full log

Message #20 received at 54292 <at> debbugs.gnu.org (full text, mbox):

From: Philip McGrath <philip <at> philipmcgrath.com>
To: Diego Nicola Barbato <dnbarbato <at> posteo.de>,
 Liliana Marie Prikler <liliana.prikler <at> ist.tugraz.at>
Cc: 54292 <at> debbugs.gnu.org, liliana.prikler <at> gmail.com
Subject: Re: Commit e8518c43 breaks guix pull on i686
Date: Tue, 08 Mar 2022 13:33:00 -0500

[Message part 1 (text/plain, inline)]

On Tuesday, March 8, 2022 10:32:48 AM EST Liliana Marie Prikler wrote:
> 
> The error appears to be that nix-system->chez-machine was rather poorly
> coded and overlooked in review.  In particular, i686 should probably
> also default to the i386 case.
> 

I must for some reason not have been thinking about the fact that Guix 
distinguishes among "i[3456]86" when I ported `%nix-arch-to-chez-alist` from 
the `raco cross` codebase.

I can see (at least) two paths forward:

  1. `%nix-{arch,os}-to-chez-alist` could become many-to-one rather than
     one-to-one. Presumably we'd use the first applicable entry when going
     from Chez to Nix.

  2. We could give up on alists and use existing predicates from (guix utils)     
     like `target-x86-32?`, as Liliana had already suggested during review for
     `chez-upstream-features-for-system`.

I liked the alists because they made the bidirectional relationship obvious, 
but I wonder if there are other potential pitfalls analogous to this one. 
Maybe someone more familiar with non-x86_64 systems in Guix/Nix than I am 
should decide.

OTOH, while it's definitely a bug that
`(nix-system->chez-machine "i686-linux")` currently returns `#f`, it seems 
like the more immediate problem is from the `maybe-compile` phase of the stex-
bootstrap package, where this code:

                        (define machine
                          #$(chez-machine->threaded
                             (nix-system->chez-machine)))

assumes, apparently incorrectly, that it's only going to be run when the 
result of `nix-system->chez-machine` is non-false. In other words, even if we 
fix the bug in `nix-system->chez-machine` for i686, I think we'd still hit 
this problem for systems that Chez really doesn't support, e.g. ppc64le or 
MIPS. I don't know what the most correct way would be to write this code, but 
I think we could defer the error until someone attempts to build the package 
for the unsupported system by just writing something like:

                        (define machine
                          #$(and=> (nix-system->chez-machine)
                                   chez-machine->threaded))

-Philip

[signature.asc (application/pgp-signature, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.