Re: Cross-compilation, Guix "system", and GNU "triplet"

[Ludovic Courtès]

Hi,

Chris Marusich <address@hidden> skribis:

> As mentioned in bug 29402 [1], Guix uses strings like "armhf-linux" to
> identify a system platform.  However, to cross-compile a package using
> Guix, you need to specify the target platform's "GNU triplet", which
> looks like "arm-linux-gnueabihf" (e.g. by invoking "guix build
> --target=arm-linux-gnueabihf hello").  These are not the same thing.
>
> OK, so Guix system "armhf-linux" maps to GNU triplet
> "arm-linux-gnueabihf".  Or perhaps a better way to think of this is that
> Guix system "armhf-linux" refers to a very specific platform choice -
> and it happens to be the case that that platform can also be identified
> by the GNU triplet "arm-linux-gnueabihf".  What about other ARM
> variants?  When we eventually get Guix running on two variants of ARM,
> will we just define another special string, like "the-second-arm-linux",
> to identify its Guix system?

The Guix system string has the form ARCHITECTURE-KERNEL, because these
are the two things not explicitly captured by the derivation graph.

The “hf” in “armhf-linux” denotes an ARMv7 processor with a hardware
floating point unit; it does not denote the ABI since the ABI is
something that’s software-defined.

As it turns out, we map “armhf-linux” to the HF ABI (“eabihf”), because
that’s the most sensible thing to do, but we could just as well map it
to the old soft-float ABI (“eabi”).

> My understanding is that multiple GNU triplets can refer to the same
> platform.  For example, I believe "arm-linux-gnueabihf" is the same as
> "arm-unknown-linux-gnueabihf" because config.sub in Autoconf translates
> the former to the latter.  Do they refer to the same platform?

Usually yes, because user-land software doesn’t care about the “vendor”
part.  It could make a difference to, say, GRUB, for which the “vendor”
part is important.

> Guix seems to treat them differently:
>
> [0] [env] address@hidden:~/guix
> $ ./pre-inst-env guix build --no-substitutes --target=arm-linux-gnueabihf 
> hello
> /gnu/store/g7cmg23ssqwknpmbbrvap60iv524i9fw-hello-2.10
> [0] [env] address@hidden:~/guix
> $ ./pre-inst-env guix build --no-substitutes 
> --target=arm-unknown-linux-gnueabihf hello
> @ build-started 
> /gnu/store/9kk7b46s836n5r0jh0sb00v8p3i5vlhg-gcc-cross-arm-unknown-linux-gnueabihf-5.4.0.drv
>  - x86_64-linux 
> /var/log/guix/drvs/9k//k7b46s836n5r0jh0sb00v8p3i5vlhg-gcc-cross-arm-unknown-linux-gnueabihf-5.4.0.drv.bz2
> ...
>
> As you can see, Guix initiated a build even though the targets are "the
> same" as far as Autoconf is concerned.  Perhaps this is because the
> strings "arm-linux-gnueabihf" and "arm-unknown-linux-gnueabihf" differ,
> which causes the derivations' output paths to differ?

Guix doesn’t try to interpret GNU triplets in any way.  So when you pass
a triplet to --target, it goes ahead and creates a cross-toolchain for
that triplet.

If turns out that Hydra has substitutes for the arm-linux-gnueabihf
cross-toolchain, but not for arm-whatever-linux-gnueabihf.

> Finally, I want to ask for some clarification regarding the "GNU
> triplet" concept in general.  Using the language of the section titled
> "Specifying Target Triplets" in the Autoconf manual, I understand that a
> GNU triplet takes the following form:
>
>     `CPU-VENDOR-OS', where OS can be `SYSTEM' or `KERNEL-SYSTEM'
>
> It seems to me that "SYSTEM" here always denotes an ABI, such as
> "gnueabihf".  Can SYSTEM ever refer to something that is NOT an ABI?

The triplet idea predates GNU/Linux, I think.  Back then, it was quite
clear what the OS was: SunOS, AIX, GNU, etc.

With glibc ported to the kernel Linux, it became useful to differentiate
between “gnu” (i.e., GNU/Hurd) and “linux-gnu”.  User-land software
often only cares about the “-gnu” part, but sometimes it needs to know
about the kernel as well.

Then people had the idea to abuse the triplet to piggyback information
about the ABI being targeted.  There are bits in the toolchain that
interpret it meaningfully.

I hope it makes sense.  :-)

Ludo’.