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
