From: Christoph Buck <buck.christoph@googlemail.com>
To: help-guix@gnu.org
Subject: Installing cross-compiled packages alongside a cross-compile toolchain
Date: Tue, 21 May 2024 10:43:11 +0200 [thread overview]
Message-ID: <82jzjny2qo.fsf@googlemail.com> (raw)
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
--
next reply other threads:[~2024-05-21 9:46 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-21 8:43 Christoph Buck [this message]
2024-06-07 20:44 ` Installing cross-compiled packages alongside a cross-compile toolchain Thiago Jung Bauermann
2024-06-11 11:17 ` Christoph Buck
2024-06-08 2:43 ` Richard Sent
2024-06-10 11:51 ` Christoph Buck
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=82jzjny2qo.fsf@googlemail.com \
--to=buck.christoph@googlemail.com \
--cc=help-guix@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).