guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Chris Marusich
Subject: Re: Cross-compilation, Guix "system", and GNU "triplet"
Date: Sat, 25 Nov 2017 13:31:08 -0800
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux)

address@hidden (Ludovic Courtès) writes:

> 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.
>
> ...
> 
> 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.
> 
> ...
>
> It’s the toolchain that shows up in the graph that determines what ABI
> is targeted.

I think I understand now.  I was missing the fact that what ABI you use
is determined by how you configure the toolchain.  I don't (yet!) know
as much about compilation, cross-compilation, and the GNU toolchain as
I'd like, so I appreciate you taking the time to explain to me what must
have seemed obvious to you.

>> 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.

OK, that makes sense.

>> For example, suppose I purchase an x86_64-linux server from a vendor
>> called FooCorp
>
> Nothing to worry about in this case.  :-)

Do you say that because if it mattered, we could just define a separate
package that takes advantage of the vendor-specific feature, like we
might do for U-Boot and GRUB?

>> 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!

Yes, I think you did.  I really appreciate it!

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

Thank you for the suggestion.  I'll keep it in mind.  It's good to know
where to go for help!

-- 
Chris

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]