- "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
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