- Don't overwrite [TARGET|HOST]_[CC|CXX] with the [CC|CXX]_WRAPPER prefix,
so that we can disable the wrapper per module.
- Disable ccache on a module when FDO is enabled.
Bug: 22612634
Change-Id: Ibc04a4742d589955066c7eceb43a0da9a2b893bc
(cherry-pick from commit c671a7cf5c)
Another change in bionic/linker adds linker_asan/linker_asan64 that
know where to find ASan shared libraries.
Also, include linker_asan to the required packages list when building
for ASan.
Change-Id: I8ebe7c0091bbeb0c135708a891d33d9844373d37
Clang is really aggressive at optimizing a handful of cases (read:
clang will ruin your day some if you write bad code). Fortunately, it
also emits a warning when it's about to do this.
To prevent anyone from suffering from these optimizations, make these
warnings errors and make them impossible to disable.
Change-Id: I5e10bb0fc2ca23190017da716b3b84635577a0bd
Clang will sometimes generate this call (dex2oat with ubsan is one
known case), and it doesn't exist in libgcc.
Change-Id: I2eb68e2a326eb0407dca03b5870077eeebca1c0a
"LOCAL_FDO_SUPPORT := always" enables FDO without user specifying
"BUILD_FDO_OPTIMIZE := true", i.e. it turns on FDO for a
module in any build configuration.
Change-Id: I05d8db2edb2b3f5db073fa14d5bf1083a04571c0
(cherry picked from commit 45d0143ab1)
Previously when a file in LOCAL_SRC_FILES starts with "../", the object
file may escape out of the module's intermediate directory, because we
insert the source file's path (but not with LOCAL_PATH) to the object
file's path. Even worse when two object files escape to the same destination
and cause conflict.
This change fixes the issue by removing the "../" inside the object
files' paths. To do that, we have to set up the compilation rules for
those files one by one, instead of using the one-for-all static
pattern rules.
Bug: 19641115
Change-Id: I19f3c48ece3244fa14acb2caa609deea710840d3
Note that this doesn't play nicely with acov out of the box. Clang
apparently generates .gcno files that aren't compatible with gcov-4.8.
This can be solved by installing gcc-4.6 and invoking lcov with
`--gcov-tool /usr/bin/gcov-4.6`.
http://stackoverflow.com/questions/17758126/clang-code-coverage-invalid-output
Change-Id: I79547e1c579fa79db47ff07d5e90c42cedbd5cbb
Don't remember why I didn't enable this for the host when I made the
first pass, but it works just fine.
Change-Id: I0892c0bc353bf8b60b432ba9f69f97281177d41d
So the build system regenerates import_includes when you modify
Android.mk to add a new dependency library.
Change-Id: Ic92b097b659bb68a9065e1d66da59e0dc7e2836a
The proto handling will modify the set of dependent libraries, but
this was not actually accounted for in dependency handling because
dependencies had already been established.
Change-Id: Iba1582f3c9eeeada19569e4b5358b6ec4168fccc
We had discussed the idea of making all host tools default to using
ASAN. Even if we don't make it the default, this makes it easy for the
user to switch all host binaries over.
Change-Id: I64a5c741b1b4e9aefed3a6be8dcd4f386e06b29c
Pass -fsanitize=address instead of manually specifying asan libraries
and other linker flags.
Note that we enable LOCAL_ALLOW_UNDEFINED_SYMBOLS by default for host
builds because ASAN only links symbols in the final executable, so
there will _always_ be undefined symbols in intermediate libraries.
Bug: 18208352
Change-Id: Ief55ab296e94974560eeb10507ec8d90f0025d5c
This will be necessary to support -std=gnu99 mode for clang 3.6, which
defaults to C11 mode (unlike prior releases that use C99).
Change-Id: Iea84582f9f12ba76b988463cbc0a20bd61042538
This feature is now available in AOSP, but not for any shipped
release. We don't have an API version for the release that this will
be available in yet, so for now the check is commented out.
Bug: 18395015
Change-Id: I247233d047ed5a7564d6602d47c9ad962313c8dc
The previous position of libgcc.a/libatomic.a on the link line causes
the linker to prefer satisfying dependencies from these libraries from
other libraries that might include them, rather than from libgcc.a (or
libatomic.a) itself. This imposes an ABI requirement that those
intermediate shared libraries _always_ export those symbols, which is
undesirable.
Change-Id: Ib593236b475d3e98356b2b1be6f96cee2b67378f
This should obviate much of the need for cleanspecs, and also make it
unnecessary to continue adding LOCAL_ADDITIONAL_DEPENDENCIES for this
sort of thing all over the tree.
Change-Id: I97aa8fd280ae868a5f6364f8b7bf3c2fe235d6ce
The NDK protobuf library depends on the final target linking stlport
(since it is a static library). Since the platform stlport is going
away, we need to use a separate version of the protobuf library that
is compiled for the platform against libc++.
Note that this should be the case for _all_ libraries built with the
NDK. If a library needs to be used by both an NDK built final target
and a platform built final target, there should be both an NDK and
platform version of the library.
Bug: 15193147
Change-Id: I0ead61c2d1cd9d0248b304ab7d8682dedd6e8366
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
