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
"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
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
Because LOCAL_CXX_STL modifies a module's required shared libaries,
we need this for also prebuilt shared libraries and executables.
Change-Id: I418c26143999a613c40aadf990f131b123e0ac3d
my_compiler_dependencies was never assigned to, but the way it was
included in the rules prevented the user from being able to use | in
LOCAL_ADDITIONAL_DEPENDENCIES. Since it is unneeded, just remove it.
Change-Id: I74bb59e81b97756296060eea5b7a42909be50130
These aren't needed now that we only use the compiler/headers that exist in
the prebuilts/clang directory.
Change-Id: I9978efb10815e92577d45629db324e0a5094f880
To enable building with coverage, the environment variable
NATIVE_COVERAGE must be set to true.
Set `LOCAL_NATIVE_COVERAGE := true` to generate coverage information for
a given component.
This is currently not supported for clang (b/17574078, b/17583330).
If static library A is included in a binary B (dynamic or static
executable, or shared library), and A is built with coverage
information, B is required to link with libgcov.a. Since the make does
not offer a good way to track this dependency, link libgcov.a even if
LOCAL_NATIVE_COVERAGE is not set (but still guarded by NATIVE_COVERAGE).
This ensures that all of the libgcov dependencies will always be
resolved, and causes no change in the resulting binary if coverage is
not used.
Bug: 10134489
Change-Id: Id5a19f2c215e4be80e6eae27ecc19b582f2f6813
