help-guix
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Debugging cross-compilation dependencies


From: Philip McGrath
Subject: Re: Debugging cross-compilation dependencies
Date: Fri, 29 Jul 2022 01:36:31 -0400
User-agent: Cyrus-JMAP/3.7.0-alpha0-758-ge0d20a54e1-fm-20220729.001-ge0d20a54

On Sat, Jul 23, 2022, at 7:30 AM, Philip McGrath wrote:
> Hi Guix,
>
> For the upcoming Racket 8.6 release, I've been trying to get the 
> Chez-Scheme–based implementation working for architectures without 
> native code-generation backends [1] and initial support for 
> cross-compilation. (Full support for cross-compilation will come after 
> there is a `racket-build-system`, since it involved building a 
> cross-compilation plugin for the compiler, and tooling for doing so 
> lives in a different package, but I had a problem during the 
> bootstrapping process with QEMU [2].)
>
> I thought I had things working at least up through 
> `chez-scheme-for-racket`, but, when I later removed the QEMU 
> binfmt_misc package from my (foreign) system, I discovered that a 
> dependency was incorrectly being cross-compiled when it needed to be 
> run on the build machine. Specifically, the problem was with Zuo (a 
> tiny Racket-like language for build scripts, [3] which replaces complex 
> makefiles in 8.6), which was particularly surprising, since it is only 
> ever used in `native-inputs`.
>
> I've put my work in progress at [4]. 

Much to my surprise, I discovered I can avoid the problem by changing code for 
#:make-flags like this:

```
#~(string-append "ZUO="
                                  #$(this-package-native-input "zuo")
                                  "/bin/zuo"))
```

to instead use `%build-inputs`, like this:

```
#~(string-append "ZUO="
                                  (search-input-file %build-inputs
                                                     "/bin/zuo"))
```

Is this expected behavior? Maybe `this-package-native-input` is supposed to 
only be used under `ungexp-native`, rather than `ungexp`?

-Philip



reply via email to

[Prev in Thread] Current Thread [Next in Thread]