The futex wrappers and memcmp16 are no longer available to anyone.
No one was checking for the existence of the SA_NOCLDWAIT constant,
and even if they wanted to, they could just check directly.
Change-Id: If8ac6c2617b76b23a2450f58fc03453f7f82a61f
- Do the module name resolving for both host and target modules.
- Check existence of both 64-bit and 32-bit module variants.
Change-Id: I8ada0e734efac6c8dafade8708fff9797b19a78d
This makes it simpler to reference normal host modules by just their
original names even if they are built for the 2nd arch.
Change-Id: I49d32dad0dc523c458d5f9176993037d8695e6a5
Otherwise we may end up conflict between LOCAL_MODULE_HOST_ARCH and the
default multilib mode.
Also removed the unneeded variants of LOCAL_MODULE_HOST_ARCH.
Change-Id: I9e5a0144da3cb6310be0ddf098738987e51305de
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
With multilib host build, the build system installs host
shared libraries to different directories depending on a
library's bitness:
- HOST_OUT_SHARED_LIBRARIES points to the library path of 64-bit;
- 2ND_HOST_OUT_SHARED_LIBRARIES points to the library path of 32-bit;
- If you don't care the bitness of the libraries and just want whatever
version the librareies are built by default, use HOST_LIBRARY_PATH.
Bug:13751317
Change-Id:Id4c818941dc4ea35d795767c76f698529bd6aebb
Also we don't need to force LLVM built from source, for we already force
LLVM to be built as 32-bit.
Bug: 13751317
Change-Id: Ifadf1988d28b60cb06316de50f5bdc1834f1acc0
The previous commit 994c84fb virtually disabled ccache, due to the
deferred evaluation of CC_WRAPPER/CXX_WRAPPER.
Change-Id: Ie0d70a23a55190bd9b24b72edc9158b6976e1d5d
This is to make it possible to wrap the compiler invocations with
custom wrappers (e.g., distcc/goma) by setting the CC_WRAPPER,
CXX_WRAPPER, JAVAC_WRAPPER variables in the build environment (without
having to know in advance the path to the compiler)
Change-Id: Ide800c24f0c2ebbb1cfb358bd8f99ec8a9d41253
Only the recovery image needs to include the recovery domain
in its policy, so create a separate policy for the recovery image
and replace the root policy with this one when building the
recovery image.
Depends on the change with the same Change-Id in external/sepolicy.
Change-Id: I444107f9821eabf4164ba07a44d03bd71e719989
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
Projects using stdatomic.h needs libatomic.a in case compiler can't
expand all __atomic* intrinsics. eg, __atomic_is_lock_free in
armeabi/mips.
Adding libatomic.a globally makes more sense than adding
"LOCAL_LDLIB += -latomic " in each project including <stdatomic.h>.
Projects don't need atomic operations won't get redundant DT_NEEDED
entry because libatomic.a is not a shared library.
Change-Id: I81dbf524544c848e667e18ab5eeabff75b5063ef
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
When the VM is libdvm, we don't put the odex files in an arch specific
subdirectory. The previous pattern rules don't work because of the extra
"/". With this change, % evaluates to empty string when it's built for
libdvm; % evaluates to "<arch_name>/" when it's built for libart.
Also removed use of $(create-empty-package), which may causes file name
(dummy) conflict with the rule of package.apk.
Bug: 15311527
Change-Id: I9f9089bc1896b78c1f47834afdb28a3a51d34480
