Hi! Total guix newbie here. Currently i am evaluating if guix could be a better alternative to yocto. My use case is as follows. I want to declarative define a system (for aarch64), generate an image and deploy it by flashing it to an sd card. Additionally i want to setup a development environment on my x64 dev machine, which i want to use to develop native applications for the aarch64 target. For this i need a cross-compile gcc toolchain (host: x64 target: aarch64) and cross-compiled packages of all libraries my application will use. Sounds like the perfect use-case for the `guix shell` command.
The first part (generating the system image) works. I managed to get the second part running as well, but only after alot of struggle and i am wondering if there is a simpler approach than the one i came up with. The first thing i tried was using the `--system=aarch64-linux` flag in the `guix shell` command, i.e `guix shell --system=aarch64-linux -m manfest.scm` where `manfest.scm` defines the compiler and all libraries my application will use. In theory this works but not only the libraries are installed as binaries for `aarch64` but the compiler as well. This means that in order to compile my application, the compiler must be run via qemu, which is too slow for my use case. Next, i tried to setup a native (x64) `aarch64-linux-gnu-` cross-compile toolchain, using the `cross-gcc-toolchain` api in `cross-base.scm`. Besides running into the bug https://issues.guix.gnu.org/68058#1-lineno32 i got it to work with the following definition im my manifest file: > (define gcc-cross-aarch64-linux-toolchain > (let ((chain (cross-gcc-toolchain "aarch64-linux-gnu"))) > (package > (inherit chain) > (native-search-paths > (package-search-paths > (lookup-package-input chain "gcc-cross-aarch64-linux-gnu")))))) > > (packages->manifest `(,gcc-cross-aarch64-linux-toolchain ,libpng)) This gives me a cross-compile toolchain but my dependency libpng is installed as x86-64bit version and i am unable to link againt it. This raises the question, how to install a native cross-compile toolchain next to libraries for the target platform. After a lot of struggle, i came up with the following solution which is inspired by the gnu guix cookbook (the section about ci, i can't link atm because gnu.org seems to be down). > (define* (enable-cross-compilation entry system target) > (manifest-entry > (inherit entry) > (name (string-append (manifest-entry-name entry) "." system > (if target > (string-append "." target) > ""))) > (item (with-parameters ((%current-system system) > (%current-target-system target)) > (manifest-entry-item entry))) > (dependencies (if (not (null? (manifest-entry-dependencies entry))) > (map (lambda (dep) (enable-cross-compilation dep system > target)) > (manifest-entry-dependencies entry)) > '())))) > (define (cross-build-package package) > (manifest (list (enable-cross-compilation (package->manifest-entry package) > "x86_64-linux" "aarch64-linux-gnu")))) > (concatenate-manifests (list (specifications->manifest '("cmake")) > (cross-build-package libpng) > (packages->manifest > `(,gcc-cross-aarch64-linux-toolchain)))) >From my rudimentary understanding of guile, this goes recursively through all manifest entries of the wrapped dependency and resets the `target` to "aarch64-linux-gnu". And indeed, this seems to work: > file > /gnu/store/kh7kl57h5i3vzx9hbbairnkkgnx7kf61-gcc-cross-aarch64-linux-gnu-11.3.0/bin/aarch64-linux-gnu-gcc > /gnu/store/kh7kl57h5i3vzx9hbbairnkkgnx7kf61-gcc-cross-aarch64-linux-gnu-11.3.0/bin/aarch64-linux-gnu-gcc: > ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), dynamically > linked, interpreter > /gnu/store/gsjczqir1wbz8p770zndrpw4rnppmxi3-glibc-2.35/lib/ld-linux-x86-64.so.2, > for GNU/Linux 2.6.32, stripped > file > /gnu/store/798dl8m0mxigjc8w3fh36iqiq0sfm8ah-libpng-1.6.37/lib/libpng16.so.16.37.0 > /gnu/store/798dl8m0mxigjc8w3fh36iqiq0sfm8ah-libpng-1.6.37/lib/libpng16.so.16.37.0: > ELF 64-bit LSB shared object, ARM aarch64, version 1 (SYSV), dynamically > linked, stripped Is this the correct way to set this up? Is there a simpler way? It is such a common problem and my solution looks rather complicated. Are there any insights and tips of people with similiar uses cases? Best regards Christoph --