chromium: Support building with NaCl #8560
Conversation
|
Tested building with enableNaCl set to both true and false with the stable channel. |
|
cc @aszlig |
|
What's the reason to switch to |
|
IMO it would make more sense to use mkChromiumDerivation instead of building NaCl together with the main derivation of the browser, which not only keeps things separate (and/or breaks the main browser for the sake of having NaCl support) but also doesn't cause a full rebuild of the main browser if someone wants to have NaCl support. |
|
I switched to stdenv_32bit, because some of the toolchain binaries were 32bit, so we need $NIX_CC/nix-support/dynamic-linker-m32 to patch it. Not sure I follow your point about mkChromiumDerivation. Do you mean build the NaCl plugin in a separate derivation, and keep the main browser common? |
|
Rebased, added stripping of everything except .nexe file, and changed to only add disable_glibc=1 if we're building with NaCl. I also looked into the possibility of moving the NaCl stuff out of common.nix, but I'm not sure it's possible. If NaCl is to be used, the main browser must be built with it. I do not think it is possible to build the browser without NaCl, then drop in the NaCl runtime + plugin later. |
|
I'm pretty sure it's possible to keep NaCl separate from the main browser, even if it's just the NaCl helpers. Going to look into that by the end of the week. |
|
I did originally download the NaCl toolchains separately, and specified the toolchain path with |
|
Does it mean that chromium is forced to be 32bit because of NaCL ? I will close this issue if that's the case. |
|
No, the produced binary is 64bit on x86_64. It's some of the downloaded toolchains that are 32bit, and require the 32bit linker. |
|
I'm currently refactoring the Chromium build, so I'd also like to get this in. However, did you try this with enabled Nix sandboxing, because it seems that it is trying to fetch stuff during build. |
This addresses NixOS#12794 so that we now have only a single tarball where we base our build on instead of splitting the source into different outputs first and then reference the outputs. The reason I did this in the first place is that we previously built the sandbox as a different derivation and unpacking the whole source tree just for building the sandbox was a bit too much. As we now have namespaces sandbox built in by default we no longer have that derivation anymore. It still might come up however if we want to build NaCl as a separate derivation (see NixOS#8560), but splitting the source code into things only NaCl might require is already too much work and doesn't weight out the benefits. Another issue with the source splitup is that Hydra now has an output limit for non-fixed-output derivations which we're already hitting. Tested the build against the stable channel and it went well, but I haven't tested running the browser. Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
Yeah, I just confirmed that it fails with build-use-chroot=true. It seems the toolchains have to be split out into a fixed-output derivation. The solution I have in mind is:
This is a bit ugly, as it will duplicate the downloading / unpacking of the toolchains into both the source.toolchain derivation and the update.sh script. If anyone has a better suggestion I'm all ears. I won't have time to look any closer at this the coming week, but I hope to have some time the week after. |
This addresses #12794 so that we now have only a single tarball where we base our build on instead of splitting the source into different outputs first and then reference the outputs. The reason I did this in the first place is that we previously built the sandbox as a different derivation and unpacking the whole source tree just for building the sandbox was a bit too much. As we now have namespaces sandbox built in by default we no longer have that derivation anymore. It still might come up however if we want to build NaCl as a separate derivation (see #8560), but splitting the source code into things only NaCl might require is already too much work and doesn't weight out the benefits. Another issue with the source splitup is that Hydra now has an output limit for non-fixed-output derivations which we're already hitting. Tested the build against the stable channel and it went well, but I haven't tested running the browser. Signed-off-by: aszlig <aszlig@redmoonstudios.org> (cherry picked from commit 4f981b4)
This addresses #12794 so that we now have only a single tarball where we base our build on instead of splitting the source into different outputs first and then reference the outputs. The reason I did this in the first place is that we previously built the sandbox as a different derivation and unpacking the whole source tree just for building the sandbox was a bit too much. As we now have namespaces sandbox built in by default we no longer have that derivation anymore. It still might come up however if we want to build NaCl as a separate derivation (see #8560), but splitting the source code into things only NaCl might require is already too much work and doesn't weight out the benefits. Another issue with the source splitup is that Hydra now has an output limit for non-fixed-output derivations which we're already hitting. Tested the build against the stable channel and it went well, but I haven't tested running the browser. Signed-off-by: aszlig <aszlig@redmoonstudios.org> (cherry picked from commit 4f981b4)
|
Updated the change to build the toolchains as a separate derivation. It's now possible to build with build-use-sandbox=true. |
| @@ -1,4 +1,4 @@ | |||
| #!/bin/sh -e | |||
| cd "$(dirname "$0")" | |||
| sp="$(nix-build -Q --no-out-link update.nix -A update)" | |||
| sp="$(nix-build -Q --no-out-link update.nix -A update --option build-use-sandbox false)" | |||
There was a problem hiding this comment.
This won't have any effect if you're running the Nix daemon.
There was a problem hiding this comment.
I assume update.sh is run manually, not through the nix daemon no? Anyway, I see that update.nix already fetches the tarballs without any hashes, so I assume this is already run outside a sandbox.
|
What I really meant with "separate derivation" was not to separate the NaCl toolchain sources but the whole NaCl helper as a separate derivation. Moreover, shouldn't NaCl be able to be used completely separate from Chromium and also its releases? I mean it has its own bytecode so it should be more or less something like "throw some bytecode at the NaCl black box and wait for something to happen", which shouldn't depend on the browser version. Am I right in this regard? |
|
As far as I can tell it's not possible to split out NaCl as a separate component. We can't just combine the NaCl runtime with a chromium binary built without NaCl and expect it to work. If you have a look at e.g. |
stable: 51.0.2704.103 -> 52.0.2743.82 beta: 52.0.2743.41 -> 53.0.2785.34 dev: 53.0.2767.4 -> 54.0.2810.2 See: http://googlechromereleases.blogspot.no/2016/07/stable-channel-update.html http://googlechromereleases.blogspot.no/2016/07/beta-channel-update-for-desktop.html http://googlechromereleases.blogspot.no/2016/07/dev-channel-update-for-desktop.html
This commits adds a new 'config.chromium.enableNaCl' option that makes it possible to build chromium with native client support enabled. The NaCl and PNaCl toolchains are required to build chromium with NaCl support. These are not part of the downloaded tarball, and must be built as a separate derivation. 'common.nix' linkes the toolchains into place if 'enableNaCl' is true. It's also been changed to do stripping manually, to avoid stripping the nacl_irt_*.nexe file, as this results in a segfault when trying to run NaCl apps.
|
I finally got it to work with PNaCl toolchains and translator built from source; no more binary blobs. The NaCl toolchains are also not tied to the chromium version, and the same toolchains can be used to build stable, beta and dev channels. Most of the information about how to build the PNaCl can be found here: |
|
PNaCl has been deprecated in favor of WebAssembly, and NaCl will soon become exclusive for Chromium OS, see: https://blog.chromium.org/2017/05/goodbye-pnacl-hello-webassembly.html Support will be removed in Q1 2018. |
If enableNaCl is true, the NaCl and PNaCl toolchains are downloaded and
patched to use the correct dynamic linker. It also disables stripping of
the installed binaries, as this seem to cause segfaults when trying to
run NaCl apps.