This needs a little bit of explanation. Normally, we would want to restructure
the code to have separate variables for "--lib32" and for the result of the
"yes_no" question. But that requires more global changes.
Instead, in this case, we want to very clearly document that we added an
early "if" statement to break out. And this is intended to be a temporary
measure until the entire feature is fully removed.
So, I instead opted for resetting the "do_inst_lib32" variable -- and a lengthy
comment explaining this decision.
BUG=233047
TEST=run with --lib32 and verify that entering "N" aborts the installation.
Review URL: https://chromiumcodereview.appspot.com/14166013
git-svn-id: http://src.chromium.org/svn/trunk/src/build@195950 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
install-build-deps.sh runs "sudo /path/to/src/build/linux/install-chromeos-fonts.py".
If the repo is on a filer, sudo fails because root is not allowed to access files on
a filer. However, installing a Repo on a Filer is not recommended.
Solution:
install-build-deps.sh attempts to detect that the Repo is not on a Filer and
in that case prints a warning with instructions.
Note: install-build-deps.sh exits immediately on failure because it uses "bash -e".
BUG=225543
R=derat@chromium.org
TEST=manual
Review URL: https://chromiumcodereview.appspot.com/13532003
git-svn-id: http://src.chromium.org/svn/trunk/src/build@192485 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
Added call to a new script in:
build/install-build-deps.sh
to download and install the ChromeOS default font
(Noto Sans UI). The installation is in:
/usr/local/share/fonts.
ChromeOS on Linux will use the font if present.
The installation creates (or recreates) a subdir:
"chromeos". In it it creates a .stamp file which is used
to avoid re-installation if it is already up to date.
It also creates a README file.
BUG=148945
TEST=manual;
One way to test is to instrument the file:
src/ui/gfx/platform_font_pango.cc
to log default_font_->GetFontName(); in ctor
PlatformFontPango::PlatformFontPango()
Expect:
W/out font installation: DejaVu Sans
With font installation: Noto Sans UI
Review URL: https://chromiumcodereview.appspot.com/12313039
git-svn-id: http://src.chromium.org/svn/trunk/src/build@184006 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
Add an option --unsupported to install-build-deps.sh which allows the
installation to be attempted on a system we don't support. Omit
mentioning this in the error, in the hope that anyone who can deal with
the fallout from this will find it in the script. Also, add GCEL
(Ubuntu-derived image used by Compute Engine) to the list of supported
systems.
BUG=
Review URL: https://codereview.chromium.org/11863012
git-svn-id: http://src.chromium.org/svn/trunk/src/build@176982 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
install-arm-sysroot.py is now seperated out from
install-build-deps.sh so that it can be invoked
independently by the gclient hooks.
This addresses a couple of different issues with
configuring the arm buildbots. Firstly it means
that they will always have an up-to-date arm
sysroot installed. Secondly, it means the script
is always run as the user (and not as root) which
mean the expanded files that the correct ownership.
BUG=
Review URL: https://chromiumcodereview.appspot.com/11468014
git-svn-id: http://src.chromium.org/svn/trunk/src/build@171990 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
Native client toolchain still need some extra 32 bit libraries belong to
packages libc6-i386 and lib32gcc1. Instead of adding all 32-bit libraries,
adding above two packages in common (64-bit and 32-bit) makes more sense.
TEST=build on 64-bit linux
BUG=138234
Review URL: https://chromiumcodereview.appspot.com/10810035
git-svn-id: http://src.chromium.org/svn/trunk/src/build@148356 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
- "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
markus@chromium.org
sschmitz@chromium.org
victorhsieh@chromium.org
xians@chromium.org
bevc@chromium.org
erg@chromium.org
torne@chromium.org
pph34r@gmail.com
sbc@chromium.org
sergeyu@chromium.org
phajdan.jr@chromium.org
mmoss@chromium.org
tfarina@chromium.org
toyoshim@chromium.org
jochen@chromium.org
halton.huo@intel.com
cmp@chromium.org
petermayo@chromium.org
bryeung@chromium.org
oshima@chromium.org
evan@chromium.org
scottmg@chromium.org
dalecurtis@chromium.org
thestig@chromium.org
mcgrathr@chromium.org
sievers@chromium.org
thakis@chromium.org
bradnelson@google.com
abarth@chromium.org