bug#55283: ‘tests/guix-shell-export-manifest.sh’ fails on aarch64-linux

[Vagrant Cascadian]

On 2022-05-06, Vagrant Cascadian wrote:
> On 2022-05-06, Vagrant Cascadian wrote:
>> On 2022-05-06, Maxime Devos wrote:
>>> raingloom schreef op vr 06-05-2022 om 02:28 [+0200]:
>>>> > …)) In guix/cpu.scm:
>>>> >       94:2  0 (cpu->gcc-architecture #f)
>>>> 
>>>> This indicates the same to me.
>>>> But I don't know the internals of --tune well enough, so it's just a
>>>> hunch.
>>>
>>> Could anyone who encounters the issue on aarch64-linux send their
>>> /proc/cpuinfo, such that other people can test the body of 'current-
>>> cpu' on that copy?
>
> What is reading from /proc/cpuinfo? I've heard it suggested that
> /proc/cpuinfo was more informational and not something to be relied on
> for anything that actually matters... ?
>
> Well, I guess I answered my initial question by reading the error
> message... guix/cpu.scm ... how did that work before for things like
> cross-building, where /proc/cpuinfo is *definitely* wrong to get
> information about the architecture you're building for?

So, the simplest reproducer is just to call what was in the test,
essentially:

  $ guix shell --export-manifest gsl openblas gcc-toolchain --tune
  Backtrace:
            10 (primitive-load "/home/vagrant/.config/guix/current/bin…")
  In guix/ui.scm:
     2230:7  9 (run-guix . _)
    2193:10  8 (run-guix-command _ . _)
  In guix/scripts/shell.scm:
     160:17  7 (guix-shell . _)
  In ice-9/boot-9.scm:
    1747:15  6 (with-exception-handler #<procedure 3cb7d8d0 at ice-9/…> …)
  In srfi/srfi-37.scm:
     201:16  5 (next-arg)
     113:18  4 (invoke-option-processor _ _ _ _ _)
  In unknown file:
             3 (_ #<procedure 3cb7d780 at srfi/srfi-37.scm:114:22 ()> # …)
             2 (_ #<procedure 3cc05060 at ice-9/boot-9.scm:798:28 ()> # …)
  In guix/transformations.scm:
     864:25  1 (_ _ _ _ ((package ad-hoc-package "gcc-toolchain") (…) …))
  In guix/cpu.scm:
       94:2  0 (cpu->gcc-architecture #f)
  
  guix/cpu.scm:94:2: In procedure cpu->gcc-architecture:
  In procedure struct-vtable: Wrong type argument in position 1 (expecting 
struct): #f

Calling "guix shell --export-manifest gsl openblas gcc-toolchain"
without the "--tune" argument works fine. So whatever codepath is not
handling cpu->gcc-architecture being #f should somehow... handle that
reasonably. Not sure what that is, as calling --tune you asked for somet
tuning and failing makes sense...

So apparently --tune is broken on aarch64 (and presumably any other
architecture that doesn't return anything). Seems cpu->gcc-architecture
should always at least return a safe baseline for all supported
architectures, maybe?


live well,
  vagrant

signature.asc
Description: PGP signature