• Cooperation
• "Install" and directories
• Kernel support for sandboxing
• System Libraries
• Source Packages
• SSE flags
• Contacts
• Distro-specific Pages

Cooperation

We are very interested in cooperating with downstream. However (as you'll see from the rest of the page) our time is limited and our team is small. Please be noisy on the mailing list or IRC if nobody responds to your issues within a day or so.

"Install" and directories

We have no "install" target. You'll need to copy the files out of the build output. Thankfully, there are only a few bits:

• the binary, chrome
• chrome.pak, which is resource data like images
• chrome_sandbox, for initial sandbox support
• a .desktop file
• xdg-settings, for "default browser" support
• a manpage, chromium-browser.1
• some other data resources in subdirectories: locales, resources, themes

Search the code for files named *_paths.cc for the logic used to compute where resources are located. Patches are welcome.

Kernel support for sandboxing

The Linux kernel must be compiled with PID_NS and NET_NS (support for process id and network namespaces) for the SUID sandbox to be fully effective.

System Libraries

Out of the box, we should build already on any modern Linux. In general, we'd like to build against more system libraries than we currently do, and some patches for this are in progress.

In the source tree, third_party/, base/third_party, and chrome/third_party/ are generally where third-party libraries live. In many of those subdirectories, there's a README.chromium with notes on local changes we may have made.

Here is a lengthy survey from December 2009 of which third-party software we've modified. In many circumstances, using the "system" version of some libraries will break functionality.

Here are some of the libraries that may require special handling:

• WebKit -- Chromium uses our own "port" of WebKit, which provides a lot of the infrastructure used for sandboxing and multiprocess. We cannot just use WebKit/GTK in the same way that QT apps can't use libwebkitgtk, but instead use libqtwebkit. Currently this port will not build as a stand alone .so, but we are moving in that direction.
• V8 -- as a C++ library, they don't worry about binary compatibility. It may be difficult to keep v8 and Chromium in sync unless you express the dependencies between a given Chromium build and a given v8 build with explicit revision numbers. See also this v8 bug.
• ICU -- As of 9 Sep 2009 we use a version of ICU 4.2.1 with a number of patches. See bug 28294.
• sqlite -- our sqlite has a huge number of patches; it would be nice to resync with trunk. For the full-text indexing used by history, I believe we've build sqlite out of a branch from their repo. We also compile with -DSQLITE_SECURE_DELETE for privacy reasons. (This info may be out of date.)
• libxml, glew: I've seen bugs filed about things breaking that I will guess are related to using the system versions of these. XXX more info needed here.

Source Packages

Our tree is enormous. A lot of it (hundreds of megabytes) is test inputs and their expected output. You can snip those from a source tree and still have something buildable.

There is src/tools/export_tarball/export_tarball.py tool to help with that. You can run it with --remove-nonessential-files flag, and it should generate a ~110 MB tar.bz2 tarball (last time checked: July 24 2009).

SSE flags

For silly reasons our default build depends on SSE, but we don't actually need. Search build/common.gypi and patch out the -msse2 bits before building your package.

Contacts

See LinuxChromiumPackages.

Distro-specific Pages

Ubuntu notes: https://wiki.ubuntu.com/Chromium/Packaging