But I don't follow why it's disabled, I see this in ebuilds: # Disable nacl, we can't build without pnacl (http://crbug.com/269560). myconf+=" -Ddisable_nacl=1" # Disable glibc Native Client toolchain, we don't need it (bug #417019). # myconf+=" -Ddisable_glibc=1" # TODO: also build with pnacl # myconf+=" -Ddisable_pnacl=1" Why cannot both (pnacl and nacl) be disabled/enabled at the same time with an unique USE flag (to save build time if desired)? Thanks for the info :)
Last time I checked it just didn't work.
was this reported or similar to upstream? (to know if something was improved before trying to re-emerge chromium with that options to test again :/)
(In reply to Paweł Hajdan, Jr. from comment #1) > Last time I checked it just didn't work. It does not work only because the ebuild is wrong. It works if the ebuild is fixed according to https://bugs.gentoo.org/show_bug.cgi?id=392347
Created attachment 403856 [details, diff] A patch to add NaCl use flag for chromium-43.0.2357.65 The patch adds NaCl use flag for chromium-43.0.2357.65.
Created attachment 437022 [details] chromium-51.0.2704.63.ebuild with nacl support This is latest stable ebuild with nacl flag included to enable building of native client for chromium.
Created attachment 445178 [details, diff] Patch for enabling NaCl in chromium-53.0.2785.92.ebuild Patch for updated chromium version (53.0.2785.92).
Can this finally be included please? Thanks
The patches that have been provided so far call download_nacl_toolchains.py in src_prepare. Downloading binaries in a src function would be an obvious QA violation, and wont even work with network-sandbox enabled. Two options: 1. Add the toolchain binaries to SRC_URI and extract them in the right place. 2. Create an ebuild to build/install the necessary toolchain, as we have done in the past.
Hey Mike, Thanks for the hint. Are you suggesting to install toolchain on the host as a separate package and put it as a dependency for building chromium? Or are you suggesting to have an additional SRC_URI in chromium ebuild and doing necessary preps in src_unpack and src_prepare? Thanks.
(In reply to Garry Filakhtov from comment #9) Yes, those are exactly the two options I presented. Option 2 only really makes sense if we are building the toolchain from source.
(In reply to Pacho Ramos from comment #7) > Can this finally be included please? Thanks Curious, what's your use case? I admit I felt somewhat discouraged to work on it since it seems nacl didn't get much usage. Ideally we'd build the toolchain from source, and I believe Fedora has managed to do so (http://pkgs.fedoraproject.org/cgit/rpms/chromium.git). We could also consider generating a tarball with downloaded binary toolchains upstream and using that - it's way easier than compiling entire toolchain from source. In that case I believe the corresponding USE flag should be masked.
I found that uploading images at web.whatsapp.com does not work without NaCl
Hey guys, I'm currently working on getting a proper ebuild, including URLs with binary upstream toolchain and unpack routines. I need nacl for several chrome apps, including chrome remote desktop app. As for building from source - it doesn't feel right, as it is only needed for building chromium and building chromium itself takes a lot of time. If we will build toolchain in addition to that it would take eternity! So at the moment, whenever I have free time, am working on getting necessary arch-dependent upstream toolchain packages and properly extracting them and then starting build process. Not much progress, but I have some strategy to keep maintenance/updating of the ebuild easier.
Also Videostream extension requires it
Created attachment 450080 [details, diff] chromium 53.0.2785.143 ebuild patch for enabling NaCL Hello Ladies and Gentlemen, I have finally finished my work on proper ebuild implementation for NaCL support. I have created src_unpack() function that in addition to extracting chromium package itself takes care of symlinking metadata and toolchain binary archives into native_client/toolchain/.tars/{linux_x86,package_archives} respectively. At a very next step I'm using download_nacl_toochain.py, but only extract function. You can safely do emerge --fetchonly, disconnect internet and build chromium offline from cached source files. As a nice bonus all ARM and MIPS binaries are ignored to save space and speed-up downloading phase. Logic inside of src_unpack() is done in a way that, if necessary to add new toolchain in addition to that already is used (pnacl_translator, pnacl_newlib and nacl_x86_newlib) you can easily do so by including respective files into SRC_URI and that's it. src_unpack() will find proper revision hashes and toolchain directories to place your new files to. I'm open for the feedback and hope we can get this into main tree soon. Greetings, Garry
Created attachment 451292 [details, diff] NaCl patch for chromium-54.0.2840.59 Hi every1, It appears that we switched to GN builds following the upstream decision, which is great. I've created another patch for latest stable version of Chromium: 54.0.2840.59 There is one caveat, though: nacl bootstrap toolchain is using clang ignoring all and any flags, so I had to create a patch to fix that issue. Everything necessary is provided in my patch, please, review and give me any suggestions/corrections. Thanks in advance. Hope to see NaCl chromium in portage tree soon!
Is there a patch for the latest versions?
Hi Andrew, Sorry, but I've gave up doing patches for every single version, because maintainers are not interested in integrating that change it seems.
Note https://blog.chromium.org/2017/05/goodbye-pnacl-hello-webassembly.html .
As per the link, Webassembly is preferred.
