all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: ludo@gnu.org (Ludovic Courtès)
To: Chris Marusich <cmmarusich@gmail.com>
Cc: guix-devel@gnu.org
Subject: Re: Guix on macOS
Date: Fri, 13 Oct 2017 14:55:46 +0200	[thread overview]
Message-ID: <87bmlbp64m.fsf@gnu.org> (raw)
In-Reply-To: <87mv4viknx.fsf@gmail.com> (Chris Marusich's message of "Fri, 13 Oct 2017 00:14:42 -0700")

Hi Chris,

Chris Marusich <cmmarusich@gmail.com> skribis:

> ludo@gnu.org (Ludovic Courtès) writes:
>
>> First of all, it’s never been a goal of Guix to run on non-GNU systems.
>> Now, I have nothing against it in principle, as long as (1) this can be
>> achieved in a maintainable way, and (2) the targeted user-land software
>> is free and buildable from source.
>
> I understand, and I agree with your criteria.
>
> I don't want to use Guix on macOS to package, promote, or make it easy
> to use non-free software.  I also don't want to port Guix to macOS in a
> way that's difficult to maintain.
>
> I want users and developers who are currently using macOS to be able to
> easily use Guix and all the free software that it provides.  To borrow
> the language used in the "GNU Emacs FAQ for MS Windows", I hope that the
> experience of using GNU Guix on macOS will give programmers a taste of
> freedom, and that this will later inspire them to move to a free
> operating system such as GNU/Linux (hopefully one that uses Guix, like
> GuixSD!) [1].  I think this is a reasonable motivation.

Understood.

At the same time, one could hope that, if freedom is not enough, the
nifty features of GuixSD, GNOME, the GNU toolchain, etc. would be enough
of an incentive to switch.  But hey, it’s complicated!

> Currently, I hope that we can get Guix working on macOS via a plan like
> the following:
>
>   1) On an x86_64-linux GuixSD system, use Guix to cross-build Guix for
>      the x86_64-darwin target [2].  We would use GNU libc.
>
>   2) Install the output of (1) on a macOS system, following a procedure
>      similar to the one in the manual for binary installation ((guix)
>      Binary Installation).
>
> Is this plan feasible? 

In theory, yes.  That’s roughly the plan outlined at
<https://www.gnu.org/software/guix/manual/html_node/Porting.html>.

Now, glibc proper only supports Linux and the Hurd.  Debian has a port
of glibc to the kernel of FreeBSD (“kFreeBSD”).  But AFAIK, these are
the only working ports of glibc.  Ricardo mentioned a glibc port to
Darwin (or XNU?), but I suspect that was very experimental no?

So your best bet would be to cross-compile using the macOS libc, similar
to what Jan did with MinGW cross-compilation support.  But again, this
is assuming that the macOS libc is free, and that both that libc and the
GNU toolchain support cross-compilation.  I don’t know if this is the
case.

> Please understand that I'm genuinely curious, and I just want to help.
> I might be missing some information that's obvious to others.  If
> there are gaps in my understanding, please help me to fill them.

Sure, I understand.  It’s a perfectly valid question to ask!

> I imagine that there might be other ways to get Guix working on macOS.
> Here are some possibilities that I've thought of or that others have
> already mentioned:
>
>   * Compile Guix (and its bootstrap binaries, I guess?) natively for
>     x86_64-darwin on macOS using Xcode, etc.  This seems undesirable for
>     a lot of reasons.  Some reasons I can think of are: the build
>     process would rely on non-free software, it probably wouldn't be
>     easily reproducible, and it would probably place a significant
>     additional burden on the Guix maintainers.  I suppose the only
>     saving grace in this case might be that once we had a working Guix
>     (with bootstrap binaries) for macOS, call it G1, we might be in a
>     position to use G1 to reproducibly build Guix (with GNU libc) on
>     macOS going forward.

I agree that this is undesirable.  :-)

>   * Run Guix compiled for x86_64-linux on macOS using some kind of a
>     shim layer.  This is pretty vague, but not without precedent:
>     consider virtual machines, WINE, and similar technologies.  This
>     seems undesirable for a lot of reasons.  Some reasons I can think of
>     are: any solution like this would probably be fragile, and as far as
>     I know there is no turn-key solution for running ELF executables on
>     macOS, so we'd have to build our own, and building our own would
>     entail the same kinds of problems as mentioned in the previous
>     bullet point.

Windows recently gained an in-kernel Linux syscall emulation, which
means that (GNU/)Linux binaries can run unmodified on Windows.

If macOS had a similar feature, that’d be perfect: we wouldn’t have
anything to do.  Perhaps Docker-for-Mac actually provides something
close to that?  I really don’t know.

>> I’m afraid this is not the answer you were looking for.  WDYT?
>
> This is exactly what I was hoping for: the start of a discussion!  If we
> can get Guix working on macOS while meeting the criteria you mentioned,
> I think it'd be great for the reasons I mentioned at the start of this
> email.  If it isn't feasible, then I'd like to understand why.

Yes, let’s see!

Thanks,
Ludo’.

  parent reply	other threads:[~2017-10-13 12:55 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-12  3:29 Guix on macOS Chris Marusich
2017-10-12  8:08 ` Konrad Hinsen
2017-10-12  8:59 ` Ludovic Courtès
2017-10-12 20:35   ` Christopher Allan Webber
2017-10-12 21:33   ` Ricardo Wurmus
2017-10-13 15:58     ` Christopher Allan Webber
2017-10-13  7:14   ` Chris Marusich
2017-10-13 11:47     ` Ricardo Wurmus
2017-10-13 12:55     ` Ludovic Courtès [this message]
2017-10-13 13:59       ` Konrad Hinsen
2017-10-13 13:59       ` Ricardo Wurmus
2017-10-13 15:59         ` Christopher Allan Webber
2017-10-13 14:08       ` Konrad Hinsen
2017-10-25 15:50         ` Adonay Felipe Nogueira
2017-10-27  4:11     ` Chris Marusich
2017-10-27  7:56       ` Hartmut Goebel
2017-10-28 20:27       ` Building Docker images of GuixSD Ludovic Courtès
2017-10-31  2:59         ` Chris Marusich
2017-11-05 15:45           ` Ludovic Courtès
2017-11-09  6:15             ` Chris Marusich
2017-11-09  6:43               ` Pjotr Prins
2017-11-09  8:23               ` Konrad Hinsen
2017-11-17 21:14               ` Ludovic Courtès
2017-11-27 22:13               ` Christopher Baines
2017-11-30  9:11                 ` Ludovic Courtès
2017-12-07  9:33                 ` Chris Marusich
2017-12-16  2:30                 ` Chris Marusich
2017-10-12 19:09 ` Guix on macOS Christopher Baines
2017-10-25 14:45 ` Adonay Felipe Nogueira
2017-10-27  1:06   ` Chris Marusich

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=87bmlbp64m.fsf@gnu.org \
    --to=ludo@gnu.org \
    --cc=cmmarusich@gmail.com \
    --cc=guix-devel@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.