08.03.2024 03:35:11 CET Jesse Millwood: > I'm still trying to get this to work. I tracked some things I forgot and > now have my channel hosted at: > https://codeberg.org/moonling/guix-embedded-dev > > When I try to build my toolchain package I get this: > > ➜ guix build -v 4 -L guix-embedded-dev ct-ng-riscv64-unknown-elf > substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0% > substitute: updating substitutes from 'https://bordeaux.guix.gnu.org'... > 100.0% > The following derivation will be built: > /gnu/store/wm1jba8npfb9jiqsbzd50gz4c89n3gjm-ct-ng-riscv64-unknown-elf-1.26.0 > .drv building > /gnu/store/wm1jba8npfb9jiqsbzd50gz4c89n3gjm-ct-ng-riscv64-unknown-elf-1.26.0 > .drv... Backtrace: > 3 (primitive-load "/gnu/store/kghq1xz3wyb509944y9jd8vhy0l?") > In ice-9/eval.scm: > 191:27 2 (_ #f) > 223:20 1 (proc #<directory (guile-user) 7ffff77f7c80>) > In unknown file: > 0 (%resolve-variable (7 . gexp) #<directory (guile-user) ?>) > > ERROR: In procedure %resolve-variable: > Unbound variable: gexp > builder for > `/gnu/store/wm1jba8npfb9jiqsbzd50gz4c89n3gjm-ct-ng-riscv64-unknown-elf-1.26. > 0.drv' failed with exit code 1 > build of > /gnu/store/wm1jba8npfb9jiqsbzd50gz4c89n3gjm-ct-ng-riscv64-unknown-elf-1.26.0 > .drv failed > View build log at > '/var/log/guix/drvs/wm/1jba8npfb9jiqsbzd50gz4c89n3gjm-ct-ng-riscv64-unknown- > elf-1.26.0.drv.gz'. guix build: error: build of > `/gnu/store/wm1jba8npfb9jiqsbzd50gz4c89n3gjm-ct-ng-riscv64-unknown-elf-1.26. > 0.drv' failed > > > It seems the issue here is an unbound variable "gexp". I'm a little > confused about this because I have #:use-module (guix gexp) included in > my package and build-system/crosstool-ng.scm files. The backtrace is a > little hard to follow.
I am self-learning Scheme and yet confident in my skills, so take what I am about to write with a dose of healthy scepticism. 1. From the error message alone, I do not know whether the unresolved variable is actually in the crosstool-ng package file, or anywhere else. 2. "gexp" or its alias "#~" do not occur in the body of the package module. However, the module does depend, among others that I trust to be correct, on the crosstool-ng build system. There is a potential for the unresolved variable to live there. 3. Upon opening the build-system file, I was quickly drawn to the nested gexp in the definition of build procedure. It took me some reading of the documentation to somewhat understand what the #$@(sexp-gexp modules) form is. My current understanding is that it brings an externally defined list of modules. 4. The (crosstool-ng-build name inputs _) definition does contain what appears to be a "modules" binding to a list of modules. That list does NOT contain (guix gexp), and this in turn makes #~(crosstool-ng-build _) form unreadable to the interpreter. Do mind that at this point the interpreter is not running inside the build-system file — it is working on a staged code of #~(begin _). 5. My proposed solution is to include (guix gexp) in the (define* (crosstool- ng-build name inputs _ (modules)) form. I have tested the change at the last minute — guix no longer complains about unresolved variables, but there is a new error about "no code for module (guix gexp)". More work needs to be put into the code overall. PS: I would appreciate it if someone who feels confident in their Scheme knowledge could grade my line of reasoning. This is my first ever attempt to debug completely foreign code.
signature.asc
Description: This is a digitally signed message part.
