From mboxrd@z Thu Jan 1 00:00:00 1970 From: Chris Marusich Subject: Re: Guix on macOS Date: Fri, 13 Oct 2017 00:14:42 -0700 Message-ID: <87mv4viknx.fsf@gmail.com> References: <87bmldavre.fsf@gmail.com> <87efq8pwrf.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:42061) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1e2uBK-000762-3O for guix-devel@gnu.org; Fri, 13 Oct 2017 03:14:55 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1e2uBI-0005nA-SD for guix-devel@gnu.org; Fri, 13 Oct 2017 03:14:54 -0400 In-Reply-To: <87efq8pwrf.fsf@gnu.org> ("Ludovic \=\?utf-8\?Q\?Court\=C3\=A8s\=22'\?\= \=\?utf-8\?Q\?s\?\= message of "Thu, 12 Oct 2017 10:59:16 +0200") List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Ludovic =?utf-8?Q?Court=C3=A8s?= Cc: guix-devel@gnu.org --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable ludo@gnu.org (Ludovic Court=C3=A8s) writes: > First of all, it=E2=80=99s never been a goal of Guix to run on non-GNU sy= stems. > 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. > I suspect macOS fails criterion #2. Back in the day (not sure if that=E2= =80=99s > still the case), Nix would bootstrap using the system=E2=80=99s compiler = and C > library (which meant that things were likely to break in subtle ways on > macOS upgrades.) > > As for criterion #1, to me, that pretty much means sticking to the GNU > libc. From my experience on Nixpkgs, having to deal with different C > libraries is a real burden. It also leads to a situation where you have > second-class systems because they use an alternate libc and it=E2=80=99s = not > uncommon for packages to fail to build against that libc. To put it > differently: it=E2=80=99s already difficult enough to have *one* OS worki= ng. I haven't yet looked at how Nix bootstraps on macOS. I'll do that and update this thread if I find any useful information to share. 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? 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. 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. * 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. I'd love to hear any other ideas anyone might have! Cross-compiling seems like one possible way forward; however, I don't know if cross-compiling is feasible. I hope it is. > I=E2=80=99m 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. Footnotes:=20 [1] https://www.gnu.org/software/emacs/manual/html_node/efaq-w32/Why-Emacs= -on-Windows.html#Why-Emacs-on-Windows [2] The string "x86_64-darwin" is used by Nix (it also shows up in some Guix files), and it seems to be synonymous with "x86_64-apple-darwin". If you run a command like "gcc -dumpmachine" on a recent version of macOS, you'll see something like "x86_64-apple-darwin16.7.0". =2D-=20 Chris --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEy/WXVcvn5+/vGD+x3UCaFdgiRp0FAlngZ+IACgkQ3UCaFdgi Rp2V9BAAuPHg4M7v4R00QKH99Gt7uNCnk3ZkM58+A+nUFmaunT+/kWPCSaGDND1w LfhOVAtJxRoGUDDrZ0lMUyFvWd2QIwLNJQfxjnyeKx6vhLvURG6fBkatP5Q/BeDn PLdTdvivbwxB8Un1Md+TNKFnI/8s61J7jO0u5wwAlBJDZ2Z7lG/oiLlADwS5tWlx NseDoZT48IUqDaF204jeN9CRlXW2Kzp/oqm/62j1tVIfpSi2MXMskG81c7TsTMfN wmOuYp82Z5jeRNygTlpkghDUrRPGkAdOeSPMOZBiU7zqqs7xk+iHnViUigD514+j C5qmqBDteUPG2XljNl/fDxjkjMgt7xYRpuWefIbBN645uTuIjlI4evHYqNoxKJ1O BVKrkNAgsXRwk7K34E9KaXGZ/bmvQah7Iar7tY/ejnvRdlF7++wCldpcAUREgh+g pVzgtmBpZA73nKaiuNBjktOrlo6hOMcqyIW6RDQ4WyOZfgsoTTdyLh80DPC7tqhr D1LJEGvxo7pjHPTxzdNXfqrTcGZoe+Xbqg7WeMs4x4ig46KQPe2TTrD8laHKXvgE lVDjXuiUminbTVlrzk6WwQW5a5QWz+CKIaPBF2RS94RWG0RkB0iLwQMJeYcjrMno Mwf3sGILfHZNWw8hAue0atzCwkn1et85hOO120kgKVV5GM6jEPw= =lqx9 -----END PGP SIGNATURE----- --=-=-=--