[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
signature.asc
Description: PGP signature
- Cross-compilation, Guix "system", and GNU "triplet", Chris Marusich, 2017/11/23
- Re: Cross-compilation, Guix "system", and GNU "triplet", Ludovic Courtès, 2017/11/24
- Re: Cross-compilation, Guix "system", and GNU "triplet", Chris Marusich, 2017/11/25
- Re: Cross-compilation, Guix "system", and GNU "triplet", Ludovic Courtès, 2017/11/25
- Re: Cross-compilation, Guix "system", and GNU "triplet",
Chris Marusich <=
- Re: Cross-compilation, Guix "system", and GNU "triplet", Chris Marusich, 2017/11/28
- Re: Cross-compilation, Guix "system", and GNU "triplet", Ludovic Courtès, 2017/11/28