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.