Bug: 18187181
Now that I checked in the latest prebuilts, clang will automatically use
color on terminals and no color on redirection to files or non-terminals.
Change-Id: I9be00c44947946cc18ce59c936b7f45d0ce2b6fc
Differences between this implementation and the old one:
1. Resolves symbols/gdb based on device information (lunch
target is irrelevant)
2. Works with downloaded from build-server symbols
3. Does not require user to specify exe file - detects it automatically
Change-Id: I4e7ce0a51868634593a9f104fe3f2fa67b54ca9f
Since acp is needed to build the ASAN libs, we can't use ASAN to
instrument it. Since libhost is included statically in acp, we can't
instrument that either.
Change-Id: Idb389df945380b6ef447fc3d3ead8be27ec09011
This assigns block device types as per device/generic/goldfish/fstab.goldfish.
Eliminates (permissive) avc: denied messages for fsck.
Change-Id: Ia72bdfb16975f051548b6b2c0636e4f907295789
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
Allow apps running with any level to write to it.
Change-Id: I8fca1f377e14c624db5273bdacf8400addc6210d
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
Only sort the list of shared libraries used for naming dependencies,
not the order they are actually linked in. The order in which shared
libraries appear to the linker affects which symbols get used if there
is a multiply defined symbol.
Also link system shared libraries _after_ user provided libraries,
since a user will want their functions to override the system's if
they exist.
Change-Id: I071059d940d40a648d69d90e0699073ef520138a
If a module is explicitly depending on a versioned protolib, we strip
the dependency and log a warning so the unneeded dependency can be
removed.
Change-Id: I949d32fb5126f1c05e2a6ed48f6636a4a9b15a48
Targeting 1.7: just adding support for the tools.
Various issues exist with OpenJDK 8: it doesn't build to completion
yet.
Change-Id: I54942f497264234e4bef488c8d17d243b4ef2f14
Atomic functions used in external/libcxx/include/atomic when compiled with Clang
will require intrinsic functions exist only for prescott or newer CPUs.
BUG: 17530542
Change-Id: I0c9660ed2ffa75b940981eb8165d88934b39aec5
Previously ccache is disabled when it fails calling clang's preprocessor with
unused arguments (such as '-Wa,--noexecstack') in the command line.
See http://petereisentraut.blogspot.com/2011/05/ccache-and-clang.html.
(-Qunused-arguments suppresses more than
-Wno-unused-command-line-argument does.)
Change-Id: I6cde307632c8395c053eb28063d7844d93070562
We no longer need gcc for host builds, since those all run through clang. This
header include, however, triggers errors about SSE intrinsics by replacing
the more relevant include dirs that we should be using.
Change-Id: I26a949f0109de8e6e2d1f09cb8127be927549cc4
Yikes. Don't know how this slipped through code review.
I had actually mentioned a need for cleanup in this part of the build
system earlier, since the amount of duplication between
transform-o-to-* for each arch means we might fix things incorrectly
in one of them (as I've just shown). Similarly, code reviewers are
likely to skim each one after the first if they all look close enough
(which is presumably what happened here).
Change-Id: I9b85914510f0b114485021deb97f42740712aae5
It is libstdc++.so, after all, and the naming makes sense for the host
this way (since it also uses libstdc++).
Change-Id: If37ffa015f7967a928ea47a290363d7696c4ce35
On some Linux distributions (spotted here on OpenMandriva Lx, but I'm
pretty sure some others do the same thing), "which javac" returns
/usr/bin/javac, which is a symlink to "../../etc/alternatives/javac",
which in turn points at whatever the JDK the user picked as his default.
Given "../../etc/alternatives/javac" is a relative symlink, the next
iteration of LSLINE=$(ls -l "$JAVAC") fails (no ../../etc/alternatives/java
relative to the build directory), causing tools.jar not to be found.
Using realpath and readlink where possible should work in all cases.
Change-Id: Ic60ac84a5b263dc1c1f2960092a7549d1024ed2e
Signed-off-by: Bernhard Rosenkraenzer <Bernhard.Rosenkranzer@linaro.org>
LPAE indicates better instructions can be used when atomicity guarantees are
needed. However, LPAE's presence isn't advertised by clang/GCC. We fake an
ARM feature to advertise its presence on architectures where it is.
Also, add a TODO documenting that cortex-a15 is not the correct CPU variant
for krait.
Change-Id: I02a1248025c32d94eca0bc8a249dc524f1ac9c36
