- "apt-cache show" is more appropriate for us then
"dpkg --print-avail"
- the test that was supposed to find the correct name for
the nspr and nss libraries didn't work correctly for
distributions (e.g. natty) that for a transition period
included both versions of the library. The new test has
been verified to work with natty.
- it is annoying that the "--clean" option sometimes fails
with a hard-to-understand error message. We now always
use "sudo" to avoid confusing users.
- apart from dbus, some distributions apparently also keep
rsyslogd running after installing the build dependencies.
If this keeps popping up as a problem, we might have to
eventually device a more generic solution.
- when the user told us to remove an old install, try to
remove all traces, instead of just the parts that cost
a lot of disk space.
BUG=none
TEST=verify that we can install natty32bit (with debug symbols) and that afterwards Chrome can be built.
Review URL: https://chromiumcodereview.appspot.com/9764004
git-svn-id: http://src.chromium.org/svn/trunk/src/build@128068 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
script to make them more userfriendly.
In particular, we now recognize systems that have multiple filesystems
(e.g. /home on NFS) and offer to do the right thing.
We also have better support for new Ubuntu distributions (both as
host and as guest). This means, we can now test on "precise".
Added a lot of extra error handling to catch common problems and either
fix them or offer suggestions on how the user can fix them. For example,
we now detect if the user tries to re-install the same chroot environment
multiple times; and we then offer to delete or overwrite the old
installation.
We also detect if a chroot environment is still in active use, and then
refuse to damage it.
In order to help users, who accidentally left an old chroot enviroment
running, we have added a "clean up" option to the wrapper script.
We automatically invoke install-build-deps.sh from install-chroot.sh,
so users only need to run install-chroot.sh and then answer a couple
of questions.
BUG=none
TEST=run install-chroot.sh on a Ubuntu machine and install both lucid32 and precise32. Verify that afterwards, we can build Chrome inside the chroot.
Review URL: https://chromiumcodereview.appspot.com/9702047
git-svn-id: http://src.chromium.org/svn/trunk/src/build@126957 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
The elfutils package is available on every Linux variant, is not very
large, and simply adds new utilities called eu-* without affecting anything
else. Packaging changes I hope to land later will need to have eu-strip
available on the buildbots that do official release builds.
BUG= none
TEST= none
R=bradnelson@google.com
Review URL: http://codereview.chromium.org/8083023
git-svn-id: http://src.chromium.org/svn/trunk/src/build@103589 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
tools/clang/scripts/update.sh tries to use curl to download over https (wget has
issues with this). To make sure curl is installed on new bots, add it to
install-build-deps.sh, so that we can use the https download on bots.
BUG=97288
TEST=none
Review URL: http://codereview.chromium.org/7966029
git-svn-id: http://src.chromium.org/svn/trunk/src/build@102566 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
The ftp.gnu.org archive got rebuilt and changed some files in place under
the same name but with rebuilt contents. The best binutils source archive
that is now available there is the 2.21.1a file, which has a verified .sig
(GPG signature) file.
BUG=none
TEST=none
Review URL: http://codereview.chromium.org/7841002
git-svn-id: http://src.chromium.org/svn/trunk/src/build@99781 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
This replaces the nacl_helper_bootstrap program, dynamically-linked against
nacl_helper.so, with a standalone, statically-linked nacl_helper_bootstrap
program that loads the dynamic linker, instructing it in turn to load the
nacl_helper program (now a PIE rather than a DSO).
This avoids two problems with the old scheme:
1. The nacl_helper_bootstrap program remained in the dynamic linker's
list of loaded objects, as the main executable, even though the
memory where its .dynamic section had been was overwritten with
the NaCl untrusted address space. Code that traverses the list of
all loaded objects could thus attempt to look at pointers into this
part of memory, and be led astray.
2. nacl_helper_bootstrap's large (~1G) bss segment could cause the kernel
to refuse to load the program because it didn't think there was enough
free memory in the system for so large an allocation of anonymous memory.
The bootstrap program is kept very small by avoiding all use of libc
(except for memset and integer division routines needed on ARM). It has
its own custom start-up code hand-written in assembly and its own custom
system call stubs done with hand-written GCC inline asm statements.
To avoid the second problem, the bootstrap program no longer has a large
bss. Instead, it has a special ELF segment (i.e. PT_LOAD header) that
specifies no memory access, and a large (~1G) mapping size from the file.
This mapping is way off the end of the file, but the kernel doesn't mind
that, and since it's all a file mapping, the kernel does not do its normal
memory accounting for consuming a large amount of anonymous memory.
Unfortunately, it's impossible to get the linker to produce exactly the
right PT_LOAD header by itself. Using a custom linker script, we get the
layout exactly how we want it and a PT_LOAD header that is almost right.
We then use a build-time helper program to munge one field of the PT_LOAD
to make it exactly what we need.
BUG= http://code.google.com/p/chromium/issues/detail?id=94147
TEST= hand-tested chromium build
R=bradchen@google.com
Review URL: http://codereview.chromium.org/7776034
git-svn-id: http://src.chromium.org/svn/trunk/src/build@99089 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
This replaces the nacl_helper_bootstrap program, dynamically-linked against
nacl_helper.so, with a standalone, statically-linked nacl_helper_bootstrap
program that loads the dynamic linker, instructing it in turn to load the
nacl_helper program (now a PIE rather than a DSO).
This avoids two problems with the old scheme:
1. The nacl_helper_bootstrap program remained in the dynamic linker's
list of loaded objects, as the main executable, even though the
memory where its .dynamic section had been was overwritten with
the NaCl untrusted address space. Code that traverses the list of
all loaded objects could thus attempt to look at pointers into this
part of memory, and be led astray.
2. nacl_helper_bootstrap's large (~1G) bss segment could cause the kernel
to refuse to load the program because it didn't think there was enough
free memory in the system for so large an allocation of anonymous memory.
The bootstrap program is kept very small by avoiding all use of libc
(except for memset and integer division routines needed on ARM). It has
its own custom start-up code hand-written in assembly and its own custom
system call stubs done with hand-written GCC inline asm statements.
To avoid the second problem, the bootstrap program no longer has a large
bss. Instead, it has a special ELF segment (i.e. PT_LOAD header) that
specifies no memory access, and a large (~1G) mapping size from the file.
This mapping is way off the end of the file, but the kernel doesn't mind
that, and since it's all a file mapping, the kernel does not do its normal
memory accounting for consuming a large amount of anonymous memory.
Unfortunately, it's impossible to get the linker to produce exactly the
right PT_LOAD header by itself. Using a custom linker script, we get the
layout exactly how we want it and a PT_LOAD header that is almost right.
We then use a build-time helper program to munge one field of the PT_LOAD
to make it exactly what we need.
BUG= http://code.google.com/p/chromium/issues/detail?id=94147
TEST= hand-tested chromium build, invoked with --nacl-linux-helper
R=bradchen@google.com,mseaborn@chromium.org
Review URL: http://codereview.chromium.org/7795010TBR=mcgrathr@chromium.org
Review URL: http://codereview.chromium.org/7811013
git-svn-id: http://src.chromium.org/svn/trunk/src/build@98910 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
This replaces the nacl_helper_bootstrap program, dynamically-linked against
nacl_helper.so, with a standalone, statically-linked nacl_helper_bootstrap
program that loads the dynamic linker, instructing it in turn to load the
nacl_helper program (now a PIE rather than a DSO).
This avoids two problems with the old scheme:
1. The nacl_helper_bootstrap program remained in the dynamic linker's
list of loaded objects, as the main executable, even though the
memory where its .dynamic section had been was overwritten with
the NaCl untrusted address space. Code that traverses the list of
all loaded objects could thus attempt to look at pointers into this
part of memory, and be led astray.
2. nacl_helper_bootstrap's large (~1G) bss segment could cause the kernel
to refuse to load the program because it didn't think there was enough
free memory in the system for so large an allocation of anonymous memory.
The bootstrap program is kept very small by avoiding all use of libc
(except for memset and integer division routines needed on ARM). It has
its own custom start-up code hand-written in assembly and its own custom
system call stubs done with hand-written GCC inline asm statements.
To avoid the second problem, the bootstrap program no longer has a large
bss. Instead, it has a special ELF segment (i.e. PT_LOAD header) that
specifies no memory access, and a large (~1G) mapping size from the file.
This mapping is way off the end of the file, but the kernel doesn't mind
that, and since it's all a file mapping, the kernel does not do its normal
memory accounting for consuming a large amount of anonymous memory.
Unfortunately, it's impossible to get the linker to produce exactly the
right PT_LOAD header by itself. Using a custom linker script, we get the
layout exactly how we want it and a PT_LOAD header that is almost right.
We then use a build-time helper program to munge one field of the PT_LOAD
to make it exactly what we need.
BUG= http://code.google.com/p/chromium/issues/detail?id=94147
TEST= hand-tested chromium build, invoked with --nacl-linux-helper
R=bradchen@google.com,mseaborn@chromium.org
Review URL: http://codereview.chromium.org/7795010
git-svn-id: http://src.chromium.org/svn/trunk/src/build@98909 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
The first time I ran it, I got an error and had to run
apt-get install -f, then re-run install-build-deps.sh.
I didn't write down the error so I don't think I can repro.
It almost works, so perhaps the next person can copy down
the error.
Review URL: http://codereview.chromium.org/2888011
git-svn-id: http://src.chromium.org/svn/trunk/src/build@52563 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
Add in two extra libraries needed for building Chromium-for-Chromium OS on a fresh install Ubuntu Lucid 64-bit. Also, start checking for header differences between the 32-bit and 64-bit packages, adding those headers into the 32-bit cons'ed up package install (on Lucid Lynx, the current libcurl4-gnutls-dev package needs this). Clean up any leftover symbolic links that point nowhere. Also take any declared package conflicts and remove them from the Provides line to allow the cons'ed up package to always install (the package derived from libcurl4-gnutls-dev).
BUG=none
TEST=none
Review URL: http://codereview.chromium.org/2865032
git-svn-id: http://src.chromium.org/svn/trunk/src/build@51863 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
- I put the dev library in the runtime section,
- I missed the runtime library (?\127libdbus-glib-1-2) altogether
- These issues were masked as apt-get couldn't resolve lib32readline-dev
replacing it with lib32readline6-dev appears to solve this.
BUG=http://crbug.com/37199
TEST=none
Review URL: http://codereview.chromium.org/811007
git-svn-id: http://src.chromium.org/svn/trunk/src/build@41276 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
BUG=none
TEST=Run install-build-deps.sh, and answer "Y" to the question "Do you want me to download all packages needed to build new 32 bit package files?". It should proceed to the installation process.
Review URL: http://codereview.chromium.org/549189
git-svn-id: http://src.chromium.org/svn/trunk/src/build@37374 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
Support (our local flavor of) hardy by dropping package sun-java6-fonts (which is broken there).
Add optional support for gold. (It would be better to not replace the system linker, but it's reversible, and works well unless you need to build wine or valgrind.)
BUG=13457
TEST=verify that this installs a working chrome dev env on clean hardy and jaunty
Review URL: http://codereview.chromium.org/119331
git-svn-id: http://src.chromium.org/svn/trunk/src/build@18175 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
systems we build and install proper Debian packages instead of directly
installing files into the filesystem.
This allows the user to cleanly uninstall the packages and it prevents
corruption from us accidentally overwriting files that the system
tries to manage itself.
Also, the script now installs debugging symbols where available. This allows
gdb to step into system libraries. The developer still needs to download the
actual source code with "apt-get source" and point the debugger to it.
Review URL: http://codereview.chromium.org/40288
git-svn-id: http://src.chromium.org/svn/trunk/src/build@11336 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
We had a bug where we weren't setting the fontdata for missing glyphs to
NULL. This caused WebKit not to try to load other fonts when glyphs
were missing.
With that fixed, we can implement the code to find a font for a given
set of code points. This uses fontconfig as it has this information
already indexed.
This fixes css2.1/t0805-c5519-brdr-r-00-a.html
Review URL: http://codereview.chromium.org/13108
git-svn-id: http://src.chromium.org/svn/trunk/src/build@6328 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
markus@chromium.org
cmp@chromium.org
oshima@chromium.org
evan@chromium.org
scottmg@chromium.org
dalecurtis@chromium.org
thestig@chromium.org
pph34r@gmail.com
mcgrathr@chromium.org
sievers@chromium.org
thakis@chromium.org
bradnelson@google.com
abarth@chromium.org
jar@chromium.org
phajdan.jr@chromium.org
dpolukhin@chromium.org
bevc@google.com
tony@chromium.org
pschmidt@google.com
mbelshe@chromium.org
sergeyu@chromium.org
ajwong@chromium.org
scottbyer@chromium.org
mdm@chromium.org
scherkus@chromium.org
zhurunz@google.com
derat@chromium.org
mmoss@google.com
maruel@chromium.org
jamesr@chromium.org
satorux@chromium.org
joth@chromium.org
nirnimesh@chromium.org
yutak@chromium.org
zork@chromium.org
dkegel@google.com
piman@chromium.org
cmasone@google.com
jrg@chromium.org
ojan@chromium.org
yusukes@google.com
fbarchard@chromium.org
mmoss@chromium.org
agl@chromium.org
dank@chromium.org
tc@google.com
sdoyon@chromium.org
evanm@google.com