1. Following the setup of gcc in build/core/combo/,
we added the [HOST|TARGET]_<arch>.mk clang config files,
and load only the configs needed by the current product.
2. Added support for the 2nd arch.
Change-Id: I2a383418a9688a050b39492f8e489d40eeeb5f2d
I don't think we can realistically turn this on for 32-bit builds any
time soon.
Also, fix the arm64 stack-protector hack.
Change-Id: Ie1e7c875bbc06fb21bb372b8ca99879a23ef53d4
Users of ARCH_ARM_* defines don't care about first vs. second arch,
set ARCH_ARM_* regardless of which arch is arm.
Change-Id: I2ae83ec5c3f839ff91a0e352c95d76ec2cbd5dc5
2ND_TARGET_DEPENDENCIES_ON_SHARED_LIBRARIES was not set,
which was causing the later += to act like = instead of
:=, and the dependencies would disappear as soon as
LOCAL_MODULE was cleared.
Change-Id: Idea291524fc06377deafec62f37d20eaa7f93bca
For whatever reason, two modules may have the same file as their
installed module. In that case circular dependency is created if the two
modules have requited-by relation.
Change-Id: I15ed271ca3f3c343e4662182ded5ccc63d6c42cc
Support the following new variables based on whether the current multilib
target is 32 bit or 64 bit:
LOCAL_CFLAGS_32
LOCAL_CFLAGS_64
LOCAL_LDFLAGS_32
LOCAL_LDFLAGS_64
LOCAL_ASFLAGS_32
LOCAL_ASFLAGS_64
LOCAL_C_INCLUDES_32
LOCAL_C_INCLUDES_64
Change-Id: Ia868d56dff114be301bf8297eec768675f186927
Host gtests that don't use pthreads themselves need to be linked
against libpthread because gtest itself uses pthreads to ensure
thread-safety. (It can't know in advance whether the code under
test is going to spin up threads, so it has to be pessimistic.)
Change-Id: I14fb1098c163d7fe6ae9a9a0314acead4ec9383d
arm and arm64 have distinct headers, but mips and mip64, and x86 and x86_64
use headers that work for both widths. So where arm/arm64 need to handle the
second architecture case specially, all we need to do for the others is
hard-code the name. (x86_64.mk already hard-codes x86; we need to change
x86.mk for the case where we're building the 32-bit binaries for a mixed
system. mips64.mk doesn't exist yet, but when it does, it'll hard-code
just plain "mips" too.)
Change-Id: Ia6b9f77b4eb2c78729b454045875c409e0ea8197
To ease the transition between toolchains, allow a target to specify
a list of cflags that the toolchain does not support. These will be
filtered out of the cflags provided by the module.
Add TARGET_GLOBAL_UNSUPPORTED_CFLAGS := -fstack-protector for the
aarch64 toolchain, it does not yet suport -fstack-protector.
Change-Id: I168d0c6f131326fad305ec86fad46e6a3e03295a
This should never have been on the default include path.
The NDK statically links its own libthread_db, so I'm removing
bionic's unused copy from devices.
Bug: 11882807
Change-Id: I49a67fe0902cc4bc178360f6c993959774d74e3a
Allow modules to generate source into $OUT/gen, which will then
be copied into $OUT/obj and $OUT/obj_$(TARGET_2ND_ARCH) as
necessary. This allows a single build rule invocation that includes
generated source to build for the first and second architectures.
Modules will need to change calls to local-intermediates-dir into
local-generated-sources-dir.
Change-Id: I62504bad9454b3d9fde7b84ab9f0a487a2ecf0bf
Using LOCAL_MODULE_PATH in a shared library module while building a
multiarch target will cause build rules for both architectures to install
into the same path. Warn and suggest LOCAL_MODULE_RELATIVE_PATH.
Change-Id: I16208ccada6d43a26a342af35096f49d8df26e81
Most users of LOCAL_MODULE_PATH are setting a subdirectory of the
normal install path, for example to install HALs into system/lib/hw.
This is problematic for multiarch builds, where the install location
depends on the arch. Allow modules to specify LOCAL_MODULE_RELATIVE_PATH.
HALs will generally use:
LOCAL_MODULE_RELATIVE_PATH := hw
Change-Id: I4e4ceec61d026bbe74ba604554c06104bde42e5e
We have no rigorous way to detect whether the code referenced for this
mechanism changes in between builds. So declare this as a phony target
so that it is rebuilt every time.
Change-Id: Ie1670d96895719d406e7b0defd53ba3cd224dd83
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
Print the name of the module that is providing an unhandled install
path.
Change-Id: I0e8b02f01de1dde715f0985034ad943f793218ba
Conflicts:
core/base_rules.mk
Set arm_objects_mode and normal_objects_mode when building a
module for arm when it is the 2nd arch.
Change-Id: I5f7df519b6e1dde6cbf92d106681f07a58e1f1f2
Compiling for arm requires using the arm kernel headers and not
the aarch64 kernel headers. Add $(combo_2nd_arch_prefix) to get
asm-$(TARGET_2ND_ARCH) when arm is the 2nd arch.
Change-Id: I15270d0ef35e48c034bf4d0d5e35b76f67b2a8e1
With those variables, you can set up different values for TARGET_ARCH
and TARGET_2ND_ARCH.
Also fixed a couple of variables.
Bug: 11654773
Change-Id: I4c7684a562cd5877d18f67d4f848b8df07d0103b
Conflicts:
core/base_rules.mk
By default, an executable is built for TARGET_ARCH.
To build it for TARGET_2ND_ARCH in a 64bit product, use:
LOCAL_32BIT_ONLY := true
To skip a module for TARGET_2ND_ARCH, use:
LOCAL_NO_2ND_ARCH := true
Bug: 11654773
Change-Id: Ieb293d25b21024bfe1b554044df338e064ac7b46
