| Message ID | 39662eaab8ebb73981be67f42a0277c2013be76b.1707855137.git.ian@retrospec.tv |
|---|---|
| State | New |
| Headers | show |
| Series | Add LibreWolf | expand |
Am Dienstag, dem 13.02.2024 um 12:34 -0800 schrieb Ian Eure: > * gnu/packages/wasm.scm (wasi-libc): New variable. > * gnu/packages/wasm.scm (wasm32-wasi-clang-runtime): New variable. > * gnu/packages/wasm.scm (wasm32-wasi-clang): New variable. > * gnu/packages/wasm.scm (wasm32-wasi-libcxx): New variable. > * gnu/packages/wasm.scm (wasm32-wasi-clang-toolchain): New variable. > --- Not sure what the result from v1-v3 is, but generally we do one package per patch. Also, if there is a reason to create a new file, what do we do with the already packaged webassembly stuff in web.scm? Cheers
Liliana Marie Prikler <liliana.prikler@gmail.com> writes: > Am Dienstag, dem 13.02.2024 um 12:34 -0800 schrieb Ian Eure: >> * gnu/packages/wasm.scm (wasi-libc): New variable. >> * gnu/packages/wasm.scm (wasm32-wasi-clang-runtime): New >> variable. >> * gnu/packages/wasm.scm (wasm32-wasi-clang): New variable. >> * gnu/packages/wasm.scm (wasm32-wasi-libcxx): New variable. >> * gnu/packages/wasm.scm (wasm32-wasi-clang-toolchain): New >> variable. >> --- > Not sure what the result from v1-v3 is, but generally we do one > package > per patch. > I have no problem splitting it up. > Also, if there is a reason to create a new file what do we do > with the already packaged webassembly stuff in web.scm? > It was like that in nonguix, where I got it from. It’s not a *good* reason, but that’s the reason. I have absolutely zero preference, so please let me know where things should go and I’ll do it. If it helps to have some options, I think these are reasonable ones, ordered by my-hot-take-descending: A. Move the two wasm packages from (gnu packages web) to (gnu packages wasm). Will require updates to anything which uses wabt, wasm3, or wasm-micro-runtime as inputs. B. Leave as-is. C. Fold the new (gnu packages wasm) into (gnu packages web). I’m not certain this is a sensible place. This has things more traditionally webby, like HTTP servers Perl cooke modules, HTML formatters, etc. The wasm packages I’m bringing over are a wasm complier and libc usable by the wasm code built with that compiler. D. Fold the new (gnu packages wasm) into (gnu packages librewolf). This is the only place they’re used, but it sounds like there’s desire to port some of the other firefoxen to this stuff, so probably not a good long-term option. In the interest of avoiding more back-and-forth, are there other structural things I should be addressing at the same time as these? This patch series has been open for three months and I’d like to get things wrapped up. — Ian
On Tue, Feb 13 2024, Ian Eure wrote: > D. Fold the new (gnu packages wasm) into (gnu packages librewolf). This is the > only place they’re used, but it sounds like there’s desire to port some of the > other firefoxen to this stuff, so probably not a good long-term option. Does Librewolf depend on the Wasm packages more than the other Firefox based browsers? My point is that if your Librewolf package is independent from the Wasm packages, they can be split and reviewed independently. That would make the Librewolf review shorter and easier, and the Wasm review more consistent and easy to test. Also, adding Wasm to our Firefox based browsers would be a one-shot. (Of course it doesn't have to be included in Icecat, but I think it would be great to have it in ‘make-torbrowser’.) It makes even more sense when considering that the author of the Wasm patches is not you (and doesn't reply). > In the interest of avoiding more back-and-forth, are there other structural > things I should be addressing at the same time as these? This patch series > has been open for three months and I’d like to get things wrapped up. Sorry, reviewing is hard. I've pushed the icu4c-73 one, and I wish to get the Wasm patch independent so that we can focus on reviewing Librewolf.
Clément Lassieur <clement@lassieur.org> writes: > On Tue, Feb 13 2024, Ian Eure wrote: > >> D. Fold the new (gnu packages wasm) into (gnu packages librewolf). This is the >> only place they’re used, but it sounds like there’s desire to port some of the >> other firefoxen to this stuff, so probably not a good long-term option. > > Does Librewolf depend on the Wasm packages more than the other Firefox > based browsers? My point is that if your Librewolf package is > independent from the Wasm packages, they can be split and reviewed > independently. > > That would make the Librewolf review shorter and easier, and the Wasm > review more consistent and easy to test. Also, adding Wasm to our > Firefox based browsers would be a one-shot. (Of course it doesn't have > to be included in Icecat, but I think it would be great to have it in > ‘make-torbrowser’.) I'd like to have support for Wasm sandboxed libraries in IceCat as well. Thanks, Mark
Clément Lassieur <clement@lassieur.org> writes: > On Tue, Feb 13 2024, Ian Eure wrote: > >> D. Fold the new (gnu packages wasm) into (gnu packages >> librewolf). This is the >> only place they’re used, but it sounds like there’s desire to >> port some of the >> other firefoxen to this stuff, so probably not a good long-term >> option. > > Does Librewolf depend on the Wasm packages more than the other > Firefox > based browsers? Upstream Librewolf doesn’t depend on the WASM packages more than any other Firefoxen. I believe that WASM sandboxing is an optional feature for recent Firefox and FF-derived browsers. In case anyone reading this isn’t familiar: Firefox has taken some libraries that handle untrusted data (which are implemented in C/C++) and complied those WASM, which it runs in isolated sandboxes. The idea being that if there’s a vulnerability in one of those libraries, the impact will be diminished becasue the exploit runs in an environment with very limited privileges[1]. > My point is that if your Librewolf package is independent from > the Wasm packages, they can be split and reviewed independently. The Librewolf package I’m submitting depends on these WASM packages; other Firefox-derived browsers currently in Guix don’t (because they can’t, because the toolchain isn’t in Guix). > That would make the Librewolf review shorter and easier, and the > Wasm > review more consistent and easy to test. Also, adding Wasm to > our > Firefox based browsers would be a one-shot. (Of course it > doesn't have > to be included in Icecat, but I think it would be great to have > it in > ‘make-torbrowser’.) > I’m not sure what you mean by "adding Wasm to our Firefox based browsers would be a one-shot." Are you saying you want a process like: 1a. Get wasm toolchain stuff merged. 1b. Get Librewolf merged without WASM sandboxing. 2. Update icecat, torbrowser, mullvad, and librewolf to use WASM sandboxing. Thanks, — Ian [1]: See https://hacks.mozilla.org/2020/02/securing-firefox-with-webassembly/ and https://blog.mozilla.org/attack-and-defense/2021/12/06/webassembly-and-back-again-fine-grained-sandboxing-in-firefox-95/ for more on this.
On Sat, Feb 17 2024, Ian Eure wrote: > Clément Lassieur <clement@lassieur.org> writes: > >> On Tue, Feb 13 2024, Ian Eure wrote: >> >>> D. Fold the new (gnu packages wasm) into (gnu packages librewolf). This is >>> the >>> only place they’re used, but it sounds like there’s desire to port some of >>> the >>> other firefoxen to this stuff, so probably not a good long-term option. >> >> Does Librewolf depend on the Wasm packages more than the other Firefox >> based browsers? > > Upstream Librewolf doesn’t depend on the WASM packages more than any other > Firefoxen. I believe that WASM sandboxing is an optional feature for recent > Firefox and FF-derived browsers. > > > In case anyone reading this isn’t familiar: Firefox has taken some libraries > that handle untrusted data (which are implemented in C/C++) and complied those > WASM, which it runs in isolated sandboxes. The idea being that if there’s a > vulnerability in one of those libraries, the impact will be diminished becasue > the exploit runs in an environment with very limited privileges[1]. > > >> My point is that if your Librewolf package is independent from the Wasm >> packages, they can be split and reviewed independently. > > The Librewolf package I’m submitting depends on these WASM packages; other > Firefox-derived browsers currently in Guix don’t (because they can’t, because > the toolchain isn’t in Guix). > > >> That would make the Librewolf review shorter and easier, and the Wasm >> review more consistent and easy to test. Also, adding Wasm to our >> Firefox based browsers would be a one-shot. (Of course it doesn't have >> to be included in Icecat, but I think it would be great to have it in >> ‘make-torbrowser’.) >> > > I’m not sure what you mean by "adding Wasm to our Firefox based browsers would > be a one-shot." Are you saying you want a process like: > > 1a. Get wasm toolchain stuff merged. > 1b. Get Librewolf merged without WASM sandboxing. > 2. Update icecat, torbrowser, mullvad, and librewolf to use WASM sandboxing. Excatly. 1b can be done after 1a, or before 1a. And if you can explain why is Mullvad Browser not "great for daily use" that would be great. https://logs.guix.gnu.org/guix/2024-02-20.log Clément
Clément Lassieur <clement@lassieur.org> writes: >> Are you saying you want a process like: >> >> 1a. Get wasm toolchain stuff merged. >> 1b. Get Librewolf merged without WASM sandboxing. >> 2. Update icecat, torbrowser, mullvad, and librewolf to use >> WASM sandboxing. > > Excatly. 1b can be done after 1a, or before 1a. > Is there a technical reason why landing WASM sandboxing support for all browsers in the same patch is desirable? I can intuit none, and as I’m disinclined to either roll back portions of my existing patchset, or work on other browsers, the proposal is disagreeable. I’m fine with splitting off the WASM toolchain stuff into a separate patch, and then merging LibreWolf afterwards. If others would like to add WASM sandboxing to their Firefox-derived browsers afterwards, they are, of course, welcome to. Is there further guidance on where the WASM toolchain packages should be placed? It seemed there was objection to having them in (gnu packages wasm), but nobody has proposed an alternate location or engaged with the options I presented. Thanks, — Ian
Am Dienstag, dem 20.02.2024 um 18:18 -0800 schrieb Ian Eure: > Clément Lassieur <clement@lassieur.org> writes: > > > > Are you saying you want a process like: > > > > > > 1a. Get wasm toolchain stuff merged. > > > 1b. Get Librewolf merged without WASM sandboxing. > > > 2. Update icecat, torbrowser, mullvad, and librewolf to use > > > WASM sandboxing. > > > > Excatly. 1b can be done after 1a, or before 1a. > > > > Is there a technical reason why landing WASM sandboxing support > for all browsers in the same patch is desirable? I can intuit > none, and as I’m disinclined to either roll back portions of my > existing patchset, or work on other browsers, the proposal is > disagreeable. I think this ordering is w.r.t. *patch sets*, not patches. I wouldn't suggest dropping four packages into one patch. > I’m fine with splitting off the WASM toolchain stuff into a > separate patch, and then merging LibreWolf afterwards. If others > would like to add WASM sandboxing to their Firefox-derived > browsers afterwards, they are, of course, welcome to. > > Is there further guidance on where the WASM toolchain packages > should be placed? It seemed there was objection to having them in > (gnu packages wasm), but nobody has proposed an alternate location > or engaged with the options I presented. Unless there's a strong reason not to, I'd place them among the existing ones in (gnu packages web). WDYT?
On Wed, Feb 21 2024, Liliana Marie Prikler wrote: > Am Dienstag, dem 20.02.2024 um 18:18 -0800 schrieb Ian Eure: >> Clément Lassieur <clement@lassieur.org> writes: >> >> > > Are you saying you want a process like: >> > > >> > > 1a. Get wasm toolchain stuff merged. >> > > 1b. Get Librewolf merged without WASM sandboxing. >> > > 2. Update icecat, torbrowser, mullvad, and librewolf to use >> > > WASM sandboxing. >> > >> > Excatly. 1b can be done after 1a, or before 1a. >> > >> >> Is there a technical reason why landing WASM sandboxing support >> for all browsers in the same patch is desirable? I can intuit >> none, and as I’m disinclined to either roll back portions of my >> existing patchset, or work on other browsers, the proposal is >> disagreeable. > I think this ordering is w.r.t. *patch sets*, not patches. I wouldn't > suggest dropping four packages into one patch. Indeed I've never said it should be done in one patch. I said one-shot as in ‘symmetrical’: the work required to add Wasm to our browsers should be more or less the same for all browsers, and code duplication should be avoided. >> I’m fine with splitting off the WASM toolchain stuff into a >> separate patch, and then merging LibreWolf afterwards. If others >> would like to add WASM sandboxing to their Firefox-derived >> browsers afterwards, they are, of course, welcome to. My point is that we need to understand the diff between a browser without wasm, and a browser with wasm. If you add librewolf with wasm already included, we don't have that diff info. And it's harder for us reviewers to understand what in your patch is wasm specific. And it's harder for us to include wasm to our firefox based browsers. I acknowledge it's more work for you, but it's a work that would have to be done otherwise by the reviewer, at least to test the wasm stuff. >> Is there further guidance on where the WASM toolchain packages >> should be placed? It seemed there was objection to having them in >> (gnu packages wasm), but nobody has proposed an alternate location >> or engaged with the options I presented. > Unless there's a strong reason not to, I'd place them among the > existing ones in (gnu packages web). > > WDYT? Agreed.
Hi Ian, Clément Lassieur <clement@lassieur.org> asked Ian Eure: > And if you can explain why is Mullvad Browser not "great for daily use" > that would be great. https://logs.guix.gnu.org/guix/2024-02-20.log I see that you also wrote about GNU IceCat in the cited IRC log: ieure (apparently Ian Eure) wrote on the #guix IRC channel: > [...] IceCat, which is weirdware Firefox that won't run non-GPL'd > JavaScript out of the box [...] For the record, this statement is incorrect. IceCat _will_ run "non-GPL'd JavaScript" out of the box. IceCat will, by default, run trivial JavaScript regardless of license, and it will also run nontrivial JavaScript that's marked as having a known free software license. There is no requirement that the JavaScript be covered by the GNU GPL. It's also easy to add sites to the whitelist, or to disable LibreJS entirely. I have no idea what you meant by "weirdware". Can you please explain what you meant by that? Thanks, Mark
Clément Lassieur <clement@lassieur.org> writes: > On Wed, Feb 21 2024, Liliana Marie Prikler wrote: >> Am Dienstag, dem 20.02.2024 um 18:18 -0800 schrieb Ian Eure: >>> Clément Lassieur <clement@lassieur.org> writes: >>> >>> > > Are you saying you want a process like: >>> > > >>> > > 1a. Get wasm toolchain stuff merged. >>> > > 1b. Get Librewolf merged without WASM sandboxing. >>> > > 2. Update icecat, torbrowser, mullvad, and librewolf to >>> > > use >>> > > WASM sandboxing. >>> > >>> > Excatly. 1b can be done after 1a, or before 1a. >>> > >>> >>> Is there a technical reason why landing WASM sandboxing >>> support >>> for all browsers in the same patch is desirable? I can intuit >>> none, and as I’m disinclined to either roll back portions of >>> my >>> existing patchset, or work on other browsers, the proposal is >>> disagreeable. >> I think this ordering is w.r.t. *patch sets*, not patches. I >> wouldn't >> suggest dropping four packages into one patch. > > Indeed I've never said it should be done in one patch. I said > one-shot > as in ‘symmetrical’: the work required to add Wasm to our > browsers > should be more or less the same for all browsers, and code > duplication > should be avoided. > Forgive me for my imprecision, and thank you for the explanation. Unfortunately, the distinction makes little difference to me, as it still would require me to do work I’m unwilling to do. My unwillingness has less to do with the amount of work than its scope: My goal is to get LibreWolf into Guix, and I simply have no desire or motivation to work on other browsers. I think the best course of action is to reduce scope by removing the WASM component of this patch series entirely. I’d send a new patch series without the WASM toolchain packages, and with WASM sandboxing disabled in the LibreWolf package. The official LibreWolf binaries don’t appear to have this enabled, so no hardening would be sacrified vs. LibreWolf installed any other way. And since I’m not the original author of the WASM packages, and not well-positioned to address problems with them, omitting them seems likely to circumvent difficulties in the review process and support of those. What do you think? Thanks, — Ian
On Wed, Feb 21 2024, Ian Eure wrote: > Clément Lassieur <clement@lassieur.org> writes: > >> On Wed, Feb 21 2024, Liliana Marie Prikler wrote: >>> Am Dienstag, dem 20.02.2024 um 18:18 -0800 schrieb Ian Eure: >>>> Clément Lassieur <clement@lassieur.org> writes: >>>> > > Are you saying you want a process like: >>>> > > > > 1a. Get wasm toolchain stuff merged. >>>> > > 1b. Get Librewolf merged without WASM sandboxing. >>>> > > 2. Update icecat, torbrowser, mullvad, and librewolf to > > use > > >>>> WASM sandboxing. >>>> > > Excatly. 1b can be done after 1a, or before 1a. >>>> > Is there a technical reason why landing WASM sandboxing support for all >>>> browsers in the same patch is desirable? I can intuit none, and as I’m >>>> disinclined to either roll back portions of my existing patchset, or work >>>> on other browsers, the proposal is disagreeable. >>> I think this ordering is w.r.t. *patch sets*, not patches. I wouldn't >>> suggest dropping four packages into one patch. >> >> Indeed I've never said it should be done in one patch. I said one-shot >> as in ‘symmetrical’: the work required to add Wasm to our browsers >> should be more or less the same for all browsers, and code duplication >> should be avoided. >> > > Forgive me for my imprecision, and thank you for the > explanation. Unfortunately, the distinction makes little difference to me, as > it still would require me to do work I’m unwilling to do. My unwillingness > has less to do with the amount of work than its scope: My goal is to get > LibreWolf into Guix, and I simply have no desire or motivation to work on > other browsers. Firefox based browsers are closely related. Sounds impossible to me to really do good work on one of them without touching the other ones. > I think the best course of action is to reduce scope by removing the WASM > component of this patch series entirely. I’d send a new patch series without > the WASM toolchain packages, and with WASM sandboxing disabled in the > LibreWolf package. The official LibreWolf binaries don’t appear to have this > enabled, so no hardening would be sacrified vs. LibreWolf installed any other > way. And since I’m not the original author of the WASM packages, and not > well-positioned to address problems with them, omitting them seems likely to > circumvent difficulties in the review process and support of those. > > What do you think? Sounds good. And we can add WASM later.
Hello, Just pinging on this. v5 of the patch reduces scope, as we discussed; it’s now just a nss update + addition of LibreWolf. Thanks, — Ian Clément Lassieur <clement@lassieur.org> writes: > On Wed, Feb 21 2024, Ian Eure wrote: > >> Clément Lassieur <clement@lassieur.org> writes: >> >>> On Wed, Feb 21 2024, Liliana Marie Prikler wrote: >>>> Am Dienstag, dem 20.02.2024 um 18:18 -0800 schrieb Ian Eure: >>>>> Clément Lassieur <clement@lassieur.org> writes: >>>>> > > Are you saying you want a process like: >>>>> > > > > 1a. Get wasm toolchain stuff merged. >>>>> > > 1b. Get Librewolf merged without WASM sandboxing. >>>>> > > 2. Update icecat, torbrowser, mullvad, and librewolf to >>>>> > > > > use > > >>>>> WASM sandboxing. >>>>> > > Excatly. 1b can be done after 1a, or before 1a. >>>>> > Is there a technical reason why landing WASM sandboxing >>>>> > support for all >>>>> browsers in the same patch is desirable? I can intuit none, >>>>> and as I’m >>>>> disinclined to either roll back portions of my existing >>>>> patchset, or work >>>>> on other browsers, the proposal is disagreeable. >>>> I think this ordering is w.r.t. *patch sets*, not patches. I >>>> wouldn't >>>> suggest dropping four packages into one patch. >>> >>> Indeed I've never said it should be done in one patch. I said >>> one-shot >>> as in ‘symmetrical’: the work required to add Wasm to our >>> browsers >>> should be more or less the same for all browsers, and code >>> duplication >>> should be avoided. >>> >> >> Forgive me for my imprecision, and thank you for the >> explanation. Unfortunately, the distinction makes little >> difference to me, as >> it still would require me to do work I’m unwilling to do. My >> unwillingness >> has less to do with the amount of work than its scope: My goal >> is to get >> LibreWolf into Guix, and I simply have no desire or motivation >> to work on >> other browsers. > > Firefox based browsers are closely related. Sounds impossible > to me to > really do good work on one of them without touching the other > ones. > >> I think the best course of action is to reduce scope by >> removing the WASM >> component of this patch series entirely. I’d send a new patch >> series without >> the WASM toolchain packages, and with WASM sandboxing disabled >> in the >> LibreWolf package. The official LibreWolf binaries don’t >> appear to have this >> enabled, so no hardening would be sacrified vs. LibreWolf >> installed any other >> way. And since I’m not the original author of the WASM >> packages, and not >> well-positioned to address problems with them, omitting them >> seems likely to >> circumvent difficulties in the review process and support of >> those. >> >> What do you think? > > Sounds good. And we can add WASM later.
diff --git a/gnu/packages/wasm.scm b/gnu/packages/wasm.scm new file mode 100644 index 0000000000..05d247f333 --- /dev/null +++ b/gnu/packages/wasm.scm @@ -0,0 +1,273 @@ +;;; GNU Guix --- Functional package management for GNU +;;; Copyright © 2022-2023 Pierre Langlois <pierre.langlois@gmx.com> +;;; +;;; This file is part of GNU Guix. +;;; +;;; GNU Guix is free software; you can redistribute it and/or modify it +;;; under the terms of the GNU General Public License as published by +;;; the Free Software Foundation; either version 3 of the License, or (at +;;; your option) any later version. +;;; +;;; GNU Guix is distributed in the hope that it will be useful, but +;;; WITHOUT ANY WARRANTY; without even the implied warranty of +;;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +;;; GNU General Public License for more details. +;;; +;;; You should have received a copy of the GNU General Public License +;;; along with GNU Guix. If not, see <http://www.gnu.org/licenses/>. + +(define-module (gnu packages wasm) + #:use-module (guix base32) + #:use-module (guix gexp) + #:use-module (guix packages) + #:use-module ((guix licenses) #:prefix license:) + #:use-module (guix utils) + #:use-module (guix git-download) + #:use-module (guix build-system cmake) + #:use-module (guix build-system gnu) + #:use-module (guix build-system trivial) + #:use-module (gnu packages bash) + #:use-module (gnu packages llvm) + #:use-module (gnu packages python)) + +(define-public wasi-libc + (package + (name "wasi-libc") + (version "sdk-19") + (source + (origin + (method git-fetch) + (uri (git-reference + (url "https://github.com/WebAssembly/wasi-libc") + (commit (string-append "wasi-" version)) + (recursive? #t))) + (file-name (git-file-name name version)) + (sha256 + (base32 "0bnpz8wk9wiic938296gxp4vz820bvpi1w41jksjzz5552hql169")))) + (build-system gnu-build-system) + (native-inputs (list clang-15)) + (arguments + (list + #:tests? #f ;No test suite + ;; Firefox uses wasm2c to compile WebAssembly to C code, and it + ;; does not support the memory.copy opcode. + ;; See https://bugzilla.mozilla.org/show_bug.cgi?id=1773200#c4 + #:make-flags ''("BULK_MEMORY_SOURCES=") + #:phases #~(modify-phases %standard-phases + (delete 'configure) + (add-before 'build 'set-sysroot-include + (lambda _ + (setenv "C_INCLUDE_PATH" + (string-append (getcwd) "/sysroot/include")))) + (add-before 'install 'set-install-dir + (lambda _ + (setenv "INSTALL_DIR" + (string-append #$output "/wasm32-wasi"))))))) + (home-page "https://wasi.dev") + (synopsis "WASI libc implementation for WebAssembly") + (description + "WASI Libc is a libc for WebAssembly programs built on top of WASI +system calls. It provides a wide array of POSIX-compatible C APIs, including +support for standard I/O, file I/O, filesystem manipulation, memory +management, time, string, environment variables, program startup, and many +other APIs.") + (license (list + ;; For wasi-libc, with LLVM exceptions + license:asl2.0 + ;; For malloc.c. + license:cc0 + ;; For cloudlibc. + license:bsd-2 + ;; For wasi-libc and musl-libc. + license:expat)))) + +(define-public wasm32-wasi-clang-runtime + (package (inherit clang-runtime-15) + (native-inputs + (list clang-15 + wasi-libc)) + (inputs (list llvm-15)) + (arguments + (list + #:build-type "Release" + #:tests? #f + ;; Stripping binaries breaks wasm linking, resulting in the following + ;; error: "archive has no index; run ranlib to add one". + #:strip-binaries? #f + #:configure-flags + #~(list "-DCMAKE_C_COMPILER=clang" + "-DCMAKE_C_COMPILER_TARGET=wasm32-wasi" + (string-append + "-DCMAKE_SYSROOT=" #$wasi-libc "/wasm32-wasi") + (string-append + "-DCMAKE_C_FLAGS=-I " #$wasi-libc "/wasm32-wasi/include") + + "-DCOMPILER_RT_OS_DIR=wasi" + + "-DCOMPILER_RT_BAREMETAL_BUILD=On" + "-DCOMPILER_RT_DEFAULT_TARGET_ONLY=On" + + ;; WASM only needs libclang_rt.builtins-wasm32.a from + ;; compiler-rt. + "../source/compiler-rt/lib/builtins"))))) + +;; FIXME: Ideally we wouldn't need to build a separate compiler because clang +;; can support multiple targets at runtime. However Guix patches the default +;; clang with a specific clang-runtime package. It would be good to improve +;; upstream Guix's support for cross-compiling with clang. + +(define clang-from-llvm (@@ (gnu packages llvm) clang-from-llvm)) +(define llvm-monorepo (@@ (gnu packages llvm) llvm-monorepo)) + +(define-public wasm32-wasi-clang + (let ((base (clang-from-llvm llvm-15 wasm32-wasi-clang-runtime))) + (package + (inherit base) + (name "wasm32-wasi-clang") + (inputs (modify-inputs (package-inputs base) + (prepend wasi-libc))) + (arguments + (substitute-keyword-arguments (package-arguments base) + ((#:configure-flags flags) + #~(list "-DCLANG_INCLUDE_TESTS=True" + ;; Use a sane default include directory. + (string-append "-DC_INCLUDE_DIRS=" + #$wasi-libc "/wasm32-wasi/include"))) + ((#:phases phases) + `(modify-phases ,phases + (delete 'symlink-cfi_ignorelist)))))))) + +(define-public wasm32-wasi-libcxx + (package + (name "wasm32-wasi-libcxx") + (version (package-version llvm-15)) + (source + (llvm-monorepo version)) + (build-system cmake-build-system) + (arguments + (list + #:configure-flags #~(list (string-append "-S ../source/runtimes") + + "-DLLVM_ENABLE_RUNTIMES=libcxx;libcxxabi" + + (string-append "-DCMAKE_SYSROOT=" + #$wasi-libc "/wasm32-wasi") + + (string-append "-DCMAKE_INCLUDE_PATH=" + #$wasi-libc + "/wasm32-wasi/include") + + (string-append "-DCMAKE_STAGING_PREFIX=" + #$output "/wasm32-wasi") + + "-DCMAKE_C_COMPILER=clang" + "-DCMAKE_C_COMPILER_WORKS=ON" + "-DCMAKE_CXX_COMPILER=clang++" + "-DCMAKE_CXX_COMPILER_WORKS=ON" + "-DCMAKE_C_COMPILER_TARGET=wasm32-wasi" + "-DCMAKE_CXX_COMPILER_TARGET=wasm32-wasi" + + "-DLIBCXX_LIBDIR_SUFFIX=/wasm32-wasi" + + "-DLIBCXX_ENABLE_EXCEPTIONS=OFF" + "-DLIBCXX_ENABLE_SHARED=OFF" + "-DLIBCXX_ENABLE_THREADS=OFF" + "-DLIBCXX_ENABLE_FILESYSTEM=OFF" + + "-DLIBCXXABI_LIBDIR_SUFFIX=/wasm32-wasi" + + "-DLIBCXXABI_ENABLE_EXCEPTIONS=OFF" + "-DLIBCXXABI_ENABLE_SHARED=OFF" + "-DLIBCXXABI_ENABLE_THREADS=OFF" + "-DLIBCXXABI_ENABLE_FILESYSTEM=OFF") + #:tests? #f + #:phases #~(modify-phases %standard-phases + (add-after 'set-paths 'adjust-CPLUS_INCLUDE_PATH + (lambda _ + (setenv "CPLUS_INCLUDE_PATH" + (string-append #$wasi-libc + "/wasm32-wasi/include:" + (getenv "CPLUS_INCLUDE_PATH")))))))) + (native-inputs (list lld python wasm32-wasi-clang)) + (inputs (list wasi-libc)) + (home-page "https://libcxx.llvm.org") + (synopsis "C++ standard library for WebAssembly") + (description + "This package provides an implementation of the C++ standard library for +use with Clang, targeting C++11, C++14 and above. This package targets +WebAssembly with WASI.") + (license license:expat))) + +(define-public wasm32-wasi-clang-toolchain + (package + (name "wasm32-wasi-clang-toolchain") + (version (package-version wasm32-wasi-clang)) + (source + #f) + (build-system trivial-build-system) + (arguments + (list + #:builder (with-imported-modules '((guix build union) + (guix build utils)) + #~(begin + (use-modules (guix build union) + (guix build utils)) + (union-build #$output + (list #$wasm32-wasi-clang-runtime + #$wasi-libc + #$wasm32-wasi-libcxx)) + (mkdir-p (string-append #$output + "/bin")) + + ;; We provide clang and clang++ via a wrapped program that sets + ;; include paths correctly so that it does not include paths from + ;; the host. + + ;; FIXME: Review how we can provide better support for + ;; cross-compiling with clang in Guix, maybe adding support for + ;; the CROSS_C_INCLUDE_PATH and CROSS_CPLUS_INCLUDE_PATH + ;; environment variables like GCC. + + (for-each (lambda (bin) + (symlink (string-append #$wasm32-wasi-clang + bin) + (string-append #$output + bin)) + (wrap-program (string-append #$output + bin) + #:sh (string-append #$bash-minimal + "/bin/bash") + `("C_INCLUDE_PATH" + ":" = + (,(string-append #$output + "/wasm32-wasi/include"))) + `("CPLUS_INCLUDE_PATH" + ":" = + ;; Make sure inclure/c++/v1 comes first for #include_next + ;; to work. + (,(string-append #$output + "/wasm32-wasi/include/c++/v1") , + (string-append #$output + "/wasm32-wasi/include"))))) + '("/bin/clang" + "/bin/clang++")) + + (symlink (string-append #$lld + "/bin/wasm-ld") + (string-append #$output + "/bin/wasm-ld")))))) + (inputs (list bash-minimal + lld + wasi-libc + wasm32-wasi-clang + wasm32-wasi-clang-runtime + wasm32-wasi-libcxx)) + (license (cons (package-license wasm32-wasi-clang) + (package-license wasi-libc))) + (home-page "https://clang.llvm.org") + (synopsis + "Complete Clang toolchain for C/C++ development, for WebAssembly.") + (description + "This package provides a complete Clang toolchain for C/C++ +development targeting WebAssembly with WASI. This includes Clang, as well as +libc, libc++ and wasm-ld.")))