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
Preparing for migration from stlport to libc++. STL selection is done
with LOCAL_CXX_STL (valid values are default, none, libc++,
libc++_static, stlport, stlport_static, bionic).
The selection of the STL is as follows:
if LOCAL_CXX_STL == 'default'
ifdef LOCAL_SDK_VERSION
Use whatever STL the other NDK options have selected.
else
Use bionic's libstdc++ for target, GNU libstdc++ for host. This
is compatible with the existing build options.
endif
else
if LOCAL_CXX_STL == 'stlport'
Use stlport.
else if LOCAL_CXX_STL == 'libc++'
Use libc++.
else if LOCAL_CXX_STL == ''
Don't use any STL.
endif
endif
Bug: 15193147
Change-Id: If712ba0ae7908d8147a69e29da5c453a183d6540
There were a few cases that my_clang was being used without being
stripped. This was causing uses like the following to fail because it
would be partially applied (use clang as the compiler, but don't strip
out incompatible cflags).
LOCAL_CLANG := true # explanation
To avoid this problem in the future, just strip my_clang when it is
assigned.
Change-Id: I41c2f36a4d4c3aa305a25b4a151c066dad5ffe0f
* commit '5b81106eb5c5c9a616874caae5ea91b45a45e9d6':
Explicitly check if LOCAL_FDO_SUPPORT is true (instead of empty). Change-Id: Icff260c7f866236254091b035782607a31e5a109
We've been using -fPIC and -fPIE together in the global cflags all this
time. These options are incompatible. The only reason we haven't been
hit by this before is because of the forced -Bsymbolic in GCC. To fix
this, pass -fpic when compiling objects for shared libraries and -fpie
when compiling objects for executables. For static libraries, also use
-fpic. We have to do this because static libraries might be included in
either a shared library or an executable. Code compiled with -fpie
cannot be included in a shared library, but code compiled with -fpic
may be included in an executable.
We've also been using -fpic and -fPIC together. These are different
options, and only the latter will take effect.
http://stackoverflow.com/a/967010
The final thing this fixes is that we had -f(PIC|PIE) flags being passed
to link commands. These are compile time flags, and don't do anything at
link time.
Bug: 16823325
Change-Id: Ic76f47e63dc2c81b7e1a8058bae1b3dc8565d606
(cherry picked from commit 4803ce2696)
We've been using -fPIC and -fPIE together in the global cflags all this
time. These options are incompatible. The only reason we haven't been
hit by this before is because of the forced -Bsymbolic in GCC. To fix
this, pass -fpic when compiling objects for shared libraries and -fpie
when compiling objects for executables. For static libraries, also use
-fpic. We have to do this because static libraries might be included in
either a shared library or an executable. Code compiled with -fpie
cannot be included in a shared library, but code compiled with -fpic
may be included in an executable.
We've also been using -fpic and -fPIC together. These are different
options, and only the latter will take effect.
http://stackoverflow.com/a/967010
The final thing this fixes is that we had -f(PIC|PIE) flags being passed
to link commands. These are compile time flags, and don't do anything at
link time.
Bug: 16823325
Change-Id: Ic76f47e63dc2c81b7e1a8058bae1b3dc8565d606
If LOCAL_CLANG is not set to false for a host module, clang will be used instead of gcc.
This also enables the integrated assembler by default for Darwin host builds.
bug 16172793
Change-Id: If7484c5dbcccce7d925bec97bff0a3e4c30e9434
Previously we only expanded product_MODULES with LOCAL_REQUIRED_MODULES,
but not modules introduced by LOCAL_SHARED_LIBRARIES; Later we did a further
shared libary expansion in vendor_module_check.mk.
It couldn't track C in the following case:
A : B, by LOCAL_SHARED_LIBRARIES; B : C, by LOCAL_REQUIRED_MODULES.
With this change, we transformed the LOCAL_SHARED_LIBRARIES dependencies
into LOCAL_REQUIRED_MODULES dependencies before doing the required
module expansion and the loophole is closed.
All module names are now expanded to product_MODULES now and it makes
vendor_module_check.mk simpler.
Change-Id: I8835a478d2ce0ce10601a8449f446f07b01c2b7f
Previously the RS cpp files are generated by the timestamp rule. Though
we have the generated RS cpp files depend on the timestamp file, we
don't have a build recipe. In such case gmake does some "optimization"
that it skip recompiling the generated cpp files, because it assumes the
generated cpp files are already up to date even if the rs files have
been updated.
Bug: 15313144
Change-Id: Ie69ecd2c788057d3619f9c7d2a125d44c4a534a1
This fixed issue that gnumake skip updating the cpp file that includes
the generated header file when the .proto file gets updated.
For example:
Say a.cc includes b.pb.h, since b.pb.h is just byproduct of the rule
that generates b.pb.cc, and though we have dependency "b.pb.h :
b.pb.cc", but we don't have build recipe for that rule.
Gmake stupidly thinks that b.pb.h must not be updated in that case so
it skips all targets that depends on b.pb.h!
With the dumy build recipe, gmake now doesn't skip the depedent targets.
Bug: 13009798
Change-Id: I39adc09b7656bdd023f578fb8933667944fd974c
