[bug#63576] [PATCH v1 0/4] Add aarch64-none-elf-gcc-toolchain.

[Denis 'GNUtoo' Carikli]

On Sun, 4 Jun 2023 11:43:16 +0300
Efraim Flashner <efraim@flashner.co.il> wrote:

> On Thu, May 18, 2023 at 08:24:34PM +0200, Denis 'GNUtoo' Carikli
> wrote:
> > Hi,
> > 
> > Here's a patch serie to add a GCC cross toolchain for
> > aarch64-none-elf. For now it doesn't contain C++ support but that
> > can be added on later.
> > 
> > I've validated by building u-boot locally with it.
> 
> I'm not entirely sure what this means. How is it different from how we
> build u-boot now?
My use case here is not to build the u-boot package but rather to build
kernels and u-boot images outside of Guix, to build not-yet
released revisions and/or to do kernel or u-boot development. 

That use case works fine if the host and target architectures are the
same as people can simply install the gcc-toolchain package. But when
it's not, it's convenient to be able to simply install packages of
cross toolchains.

Some distributions like Arch Linux[1], Debian[2], Ubuntu[3], and their
derivatives (Parabola, PureOS, Trisquel, etc) do provide packages for
cross toolchains.

Here I've confirmed that the patches I submitted work fine by
building u-boot from source (for aarch64) on an x86 laptop running Guix
and by running the resulting u-boot images on hardware like the
Pinephone
(with u-boot patched to not use crust, and I didn't try to boot Linux)
and the Rock 4C plus (this was more extensively tested than the
Pinephone, I booted a Guix image on it etc).

However I am unsure if the approach I took with my patch serie is the
way to go here as here we have some duplication as some of the toolchain
packages generated specifically for u-boot are for the exact same
architecture (here aarch64). I also plan to add more toolchain
packages (at least for or1k, RISCV 32). So at the end it kind of
doubles the maintenance.

In another hand my approach works and it also doesn't interfere with
u-boot packages (so we don't have a risk of u-boot breakages when my
toolchain packages are updated).

What approach do you think would be best? Do you have ideas of better
approaches than the ones I proposed here?

PS: I also noticed later on that I need to update newlib to 4.1.0, but I
    can do that with a v2 or in a later patch depending on what you
    think is best.

PPS: Note that when building u-boot or kernels locally (not as
     packages), in addition to the toolchain, there are also some tricks
     needed to make things work out of the box.

     For u-boot I use 'guix shell -D u-boot-rockpro64-rk3399 openssl@3
     python python-pyelftools'. As I don't have to redistribute the
     binaries I didn't look into not using openssl@3, but I'll have to
     look into it at some point.

     I then have to pass HOSTCC=gcc to make as cc isn't defined. I
     also have to pass the usual CROSS_COMPILE=, BL31=, etc to make.

     For xconfig I have to use something like that:
     'PKG_CONFIG_PATH=/gnu/store/[...]-qtbase-5.15.8/lib/pkgconfig/
     make ARCH=arm HOSTCC=gcc xconfig'.

References:
-----------
[1]https://archlinux.org/packages/extra/x86_64/aarch64-linux-gnu-gcc/
[2]https://packages.debian.org/bullseye/gcc-10-aarch64-linux-gnu
[3]https://packages.ubuntu.com/kinetic/gcc-10-aarch64-linux-gnu

Denis.

pgpXm9h8Qz1AZ.pgp
Description: OpenPGP digital signature