From: Chris Marusich <cmmarusich@gmail.com>
To: "Ludovic Courtès" <ludo@gnu.org>
Cc: guix-devel@gnu.org
Subject: Re: Cross-compilation, Guix "system", and GNU "triplet"
Date: Sat, 25 Nov 2017 13:31:08 -0800 [thread overview]
Message-ID: <87bmjqoxk3.fsf@gmail.com> (raw)
In-Reply-To: <87a7zaxqc1.fsf@gnu.org> ("Ludovic \=\?utf-8\?Q\?Court\=C3\=A8s\=22'\?\= \=\?utf-8\?Q\?s\?\= message of "Sat, 25 Nov 2017 17:42:22 +0100")
[-- Attachment #1: Type: text/plain, Size: 2587 bytes --]
ludo@gnu.org (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 #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
next prev parent reply other threads:[~2017-11-25 21:31 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-24 0:46 Cross-compilation, Guix "system", and GNU "triplet" Chris Marusich
2017-11-24 13:50 ` Ludovic Courtès
2017-11-25 9:40 ` Chris Marusich
2017-11-25 16:42 ` Ludovic Courtès
2017-11-25 21:31 ` Chris Marusich [this message]
2017-11-28 5:58 ` Chris Marusich
2017-11-28 16:05 ` Ludovic Courtès
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87bmjqoxk3.fsf@gmail.com \
--to=cmmarusich@gmail.com \
--cc=guix-devel@gnu.org \
--cc=ludo@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/guix.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.