-
-
Notifications
You must be signed in to change notification settings - Fork 14.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Build Chromium from source #14
Closed
Closed
+268
−59
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This only gets chromium to build so far, installation is missing by upstream, so we need to manually copy the corresponding files. And I guess with nix, we also need to patch a few paths on installation. Another issue is that at the moment, a lot of dependencies are used from the source tree, rather than from the system. Also, it would be nice to build using LLVM, as it really speeds up compilation a *LOT* and also has the side effect of resulting in smaller binaries. Working unit tests would be nice, too. Unfortunately they're quite heavyweight and take hours to run, so I guess "someday" would be the most appropriate time to integrate. Further todo's: - Allow to disable GConf, GIO and CUPS. - Option to disable the sandbox (for whatever reason the user might have). - Integrate gold binutils. - Pulseaudio support. - Clearly separate Linux specific stuff.
This tries to put pathes unte the same directory as the previous prebuilt version of Chromium.
It fetches the latest version based on the bucketlist XML from commondatastorage and generates a "source.nix" which contains an attribute set about where to fetch the latest version. The XML is parsed in a somewhat hackish way using sed, but as this is just an updater, its okay and we don't want to break a fly on the wheel by employing a full XML parser.
This also includes setting compiler architectures and paths.
If useSELinux is not set, enable seccomp mode by default and avoid building the SUID helper sandbox at all. This involves a small patch which causes the commandline arguments to be swapped: --disable-seccomp-sandbox to disable it, while the option is active by default.
This is needed by a lot of scripts within chromium, so we're not going to patch them using type, which is shell-specific anyway.
There are still some libraries left, which we either need to patch or provide more recent versions. Plus we're going to use openssl, as libnss doesn't want to do proper SSL (let's debug this later).
This is to make it more consistent with the naming of the package file and also consistent with the build, as we're not using the Google branded version. In addition the derivation attribute set now has a packageName value which can be used to easily switch the binary names and paths, just in case we want to switch to using "chrome" (or something entirely different) again.
This is mainly because of the patch to use OPENSSL_X509_CERT_FILE as a way to specify the CA bundle. A browser which isn't able to verify SSL certificates might be somewhat useless.
Currently building fails with NSS, so we're using OpenSSL by default. And that's why we want to make this configurable so if we manage to fix that build failure, we could switch to using NSS by default.
This also separates gcrypt and gconf from the basic dependencies. Unfortunately we cannot get rid of dbus_glib altogether, but maybe we want to work on a patch to get rid of it? On the other hand it seems to be a TODO of the chromium project itself, so let's wait and see.
This finally enables support for WebGL and accelerated rendering.
We also need to patch the compilation process, so it allows deprecated declarations when building support for the cups backend. In addition, we also need to add libgcrypt to dependencies as it's needed by the cups implementation.
We now switch to using bundled ffmpeg, as this adds stuff such as support for the H.264 codec.
This doesn't really work at the current state of NixOS and SELinux support, but will make it easier in case we someday support SELinux altogether.
This mostly is a code structure change, but also involves deleting some unused dependencies and adding a few constraints on existing ones.
These libraries are heavily patched by the chromium project itself, so let's use the bundled versions as those won't build anyway and also don't break functional purity.
This makes it easier to remember, as so far the naming wasn't quite consistent, sometimes "use*", sometimes "enable*". So in using just use the feature name itself, it should be pretty clear.
Which is enabled by default if neither pulseaudio or chromium.pulseaudio is explicitly set. The reason is that chromium falls back to ALSA in case no pulseaudio is available. In addition it was necessary to patch media.gyp to ignore the array-out-of- bounds warning.
Always did this manually by putting -j8 into make flags, which i didn't commit, as it obviously doesn't make sense to hardcode. However, this flag makes more sense and obviously we need to avoid overriding buildPhase.
ocharles
added a commit
that referenced
this pull request
Nov 18, 2014
mguentner
pushed a commit
to mguentner/nixpkgs
that referenced
this pull request
Dec 4, 2016
Closed
srhb
pushed a commit
to srhb/nixpkgs
that referenced
this pull request
Feb 21, 2018
…of it building an environment from config attrSets - ref NixOS#14
srhb
pushed a commit
to srhb/nixpkgs
that referenced
this pull request
Feb 21, 2018
srhb
pushed a commit
to srhb/nixpkgs
that referenced
this pull request
Feb 21, 2018
srhb
pushed a commit
to srhb/nixpkgs
that referenced
this pull request
Feb 21, 2018
… delete it after stopping, to housekeep the system - ref NixOS#14
10 tasks
Closed
Profpatsch
pushed a commit
that referenced
this pull request
Jun 20, 2020
ethancedwards8
pushed a commit
to ethancedwards8/nixpkgs
that referenced
this pull request
Apr 2, 2021
primeos
added a commit
to primeos/nixpkgs
that referenced
this pull request
May 27, 2021
FAIL: LLVM :: DebugInfo/X86/vla-multi.ll (25780 of 42068) ******************** TEST 'LLVM :: DebugInfo/X86/vla-multi.ll' FAILED ******************** Script: -- : 'RUN: at line 1'; /build/llvm/build/bin/llc -mtriple=x86_64-apple-darwin /build/llvm/test/DebugInfo/X86/vla-multi.ll -o - -filetype=obj | /build/llvm/build/bin/llvm-dwarfdump - | /build/llvm/build/bin/FileCheck --allow-unused-prefixes=false /build/llvm/test/DebugInfo/X86/vla-multi.ll -- Exit Code: 2 Command Output (stderr): -- PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash backtrace. Stack dump: 0. Program arguments: /build/llvm/build/bin/llc -mtriple=x86_64-apple-darwin /build/llvm/test/DebugInfo/X86/vla-multi.ll -o - -filetype=obj #0 0x00007ffff286ac1d llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/build/llvm/build/lib/libLLVM-12.so+0xd51c1d) #1 0x00007ffff2868924 llvm::sys::RunSignalHandlers() (/build/llvm/build/lib/libLLVM-12.so+0xd4f924) #2 0x00007ffff2868a9b SignalHandler(int) (/build/llvm/build/lib/libLLVM-12.so+0xd4fa9b) #3 0x00007ffff1b0b700 __restore_rt (/nix/store/sbbifs2ykc05inws26203h0xwcadnf0l-glibc-2.32-46/lib/libpthread.so.0+0x13700) #4 0x00007ffff31c2430 llvm::DIE::getUnitDie() const (/build/llvm/build/lib/libLLVM-12.so+0x16a9430) NixOS#5 0x00007ffff31e0f5c llvm::DwarfDebug::finishEntityDefinitions() (/build/llvm/build/lib/libLLVM-12.so+0x16c7f5c) NixOS#6 0x00007ffff31f9415 llvm::DwarfDebug::finalizeModuleInfo() (/build/llvm/build/lib/libLLVM-12.so+0x16e0415) NixOS#7 0x00007ffff31fc558 llvm::DwarfDebug::endModule() (/build/llvm/build/lib/libLLVM-12.so+0x16e3558) NixOS#8 0x00007ffff31ab659 llvm::AsmPrinter::doFinalization(llvm::Module&) (/build/llvm/build/lib/libLLVM-12.so+0x1692659) NixOS#9 0x00007ffff29ab77d llvm::FPPassManager::doFinalization(llvm::Module&) (.localalias) (/build/llvm/build/lib/libLLVM-12.so+0xe9277d) NixOS#10 0x00007ffff29b7570 llvm::legacy::PassManagerImpl::run(llvm::Module&) (/build/llvm/build/lib/libLLVM-12.so+0xe9e570) NixOS#11 0x0000000000415bbf compileModule(char**, llvm::LLVMContext&) (/build/llvm/build/bin/llc+0x415bbf) NixOS#12 0x000000000040e582 main (/build/llvm/build/bin/llc+0x40e582) NixOS#13 0x00007ffff162aded __libc_start_main (/nix/store/sbbifs2ykc05inws26203h0xwcadnf0l-glibc-2.32-46/lib/libc.so.6+0x27ded) NixOS#14 0x000000000040eb5a _start /build/glibc-2.32/csu/../sysdeps/x86_64/start.S:122:0 error: -: The file was not recognized as a valid object file FileCheck error: '<stdin>' is empty. FileCheck command line: /build/llvm/build/bin/FileCheck --allow-unused-prefixes=false /build/llvm/test/DebugInfo/X86/vla-multi.ll -- ********************
j-openmesh
referenced
this pull request
in Openmesh-Network/Xnodepkgs
Jul 7, 2024
Feature/xnode admin service
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
NixOS currently uses the binary release of Chromium.
With these changes, it should no longer be the case.
Everything is working so far, except NaCl, which is is disabled for now.
It didn't work in the previous binary release version, so I guess noone should be unhappy about it.
Though getting it to work is on my todo list, at the very latest when I want to play around with it again... someday.
Plus a few dependencies are the bundled one with chromium, as they contain too many patches to allow for nice integration into nixpkgs, but those that would break functional purity are used from nixpkgs.