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

[Ludovic Courtès]

Heya,

Chris Marusich <address@hidden> skribis:

> address@hidden (Ludovic Courtès) writes:
>
>> The Guix system string has the form ARCHITECTURE-KERNEL, because these
>> are the two things not explicitly captured by the derivation graph.
>
> I see.  When you say that something is "captured by the derivation
> graph," do you mean that it is part of the hash calculation, so it
> influences a derivation's store path as well as the derivation's
> outputs' store paths?

What I meant is that, in the functional model as implemented in
Nix/Guix, the derivation graph captures all user-land software that
comes into play.  But it does not capture the hardware and kernel, both
of which are taken from granted.

Thus, this system string allows us to represent the dependency on a
kernel and hardware architecture.  In turn, this allows us to
distinguish between, say, the Guile derivation for x86_64 and that for
MIPS.

> Other than the Guix system string, what things are "captured by the
> derivation graph" (either explicitly or implicitly)?  For example, is
> the ABI captured by the derivation graph?  What about the vendor?  What
> about the executable file format (e.g., ELF vs. some other possibility)?
> Anything else?

The ABI and file format are entirely (or almost entirely) the
responsibility of user-land software (how you configure the toolchain
determines what ABI you use, for instance.)  Thus they’re necessarily
captured by the dependency graph; no need to store that information
elsewhere.

The vendor doesn’t matter on Intel machines.  It matters on ARM, but
only for specific things like the bootloader and the kernel.

>> 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 when a derivation's system is "armhf-linux", it
> means that the derivation itself (as opposed to its output) is intended
> to be built (i.e., the derivation's builder is intended to be run) on
> the "armhf-linux" platform.  If the Guix system string does not contain
> details like the ABI, then how does Guix differentiate between the case
> in which the derivation is built on an ARM system that uses the HF ABI,
> and the case in which it is built on an ARM system that uses the
> soft-float ABI?

It’s the toolchain that shows up in the graph that determines what ABI
is targeted.

>> 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.
>
> What is the recommended way to package software in Guix when the
> software's behavior or the output of the derivation that builds it can
> be influenced by the value of the "vendor" part?

There are two or three examples of that, which are U-Boot, GRUB, and
Linux-libre.  We essentially define several package variants for each of
these, depending on the target hardware.

> For example, suppose I purchase an x86_64-linux server from a vendor
> called FooCorp

Nothing to worry about in this case.  :-)

> Yes, I understand.  The GNU triplet concept makes more sense to me now.
> However, if information like the vendor and the OS/ABI are important
> enough to put into the GNU triplet, I still don't understand why we can
> get away with omitting those details from the Guix system string.

I hope I answered that question!

That said, you may get better-informed answers on the GCC or Binutils
mailing lists.  :-)

Ludo’.