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
* commit 'd69ed2e25c59803bbbbbee7c09551efb3ed0c49d':
add support for more LOCAL_*_arch variables
don't rename 32-bit executables to *_32
remove 2nd arch from ARCH_ARM_* defines
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
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
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
The rules for the 2nd arch are set up in the second inclusion
of shared_library_internal.mk.
Intermediate fils of libfoo of the 2nd arch will be built into
$(PRODUCT_OUT)/obj_$(TARGET_2ND_ARCH)/SHARED_LIBRARIES/libfoo_intermediates/
and the built libfoo.so will be in
$(PRODUCT_OUT)/obj_$(TARGET_2ND_ARCH)/lib.
Bug: 11654773
Change-Id: I58bbe5a05a65f63bce6279131552f3792000716e
The rules for the 2nd arch are set up in the second inclusion
of static_library_internal.mk.
libfoo of the 2nd arch will be built into
$(PRODUCT_OUT)/obj_$(TARGET_2ND_ARCH)/libfoo_intermediates/libfoo.a.
Bug: 11654773
Change-Id: I1d92733968fc442e9225b4df5bd1b551a81d89f7
This is the first step to build 32-bit libraries in a 64-bit product.
It will work like this:
1) In the product's BoardConfig.mk, define:
TARGET_2ND_ARCH, TARGET_2ND_ARCH_VARIANT, TARGET_2ND_CPU_VARIANT.
The build system uses those variables to set up an additional compiler
environment for the second arch.
2) When parsing Android.mks, the build system sets up rules to build a
module for both the 1st arch and the 2nd arch, unless it's explicitly
asked to skip so.
Android.mk will be adapted if there is additional rule of generating
source files.
The build system will accept arch-specific LOCAL_ variables, such as
LOCAL_CFLAGS_arm, LOCAL_CFLAGS_armv7-a-neon, LOCAL_CFLAGS_cortex-a15,
LOCAL_CFLAGS_aarch64 etc. Modules use such variables to set up build for
various archs at the same time.
3) Install binary of the 2nd arch by adding "<module_name>:32" to
PRODUCT_PACKAGES. All 2nd-arch libraries linked in by "<module_name>:32"
will be installed automatically.
Bug: 11654773
Change-Id: I2df63cd5463a07bf5358bee2a109f8fb9590fe30
Conflicts:
core/combo/TARGET_linux-arm.mk
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
The rules for the 2nd arch are set up in the second inclusion
of shared_library_internal.mk.
Intermediate fils of libfoo of the 2nd arch will be built into
$(PRODUCT_OUT)/obj_$(TARGET_2ND_ARCH)/SHARED_LIBRARIES/libfoo_intermediates/
and the built libfoo.so will be in
$(PRODUCT_OUT)/obj_$(TARGET_2ND_ARCH)/lib.
Bug: 11654773
Change-Id: I58bbe5a05a65f63bce6279131552f3792000716e
The rules for the 2nd arch are set up in the second inclusion
of static_library_internal.mk.
libfoo of the 2nd arch will be built into
$(PRODUCT_OUT)/obj_$(TARGET_2ND_ARCH)/libfoo_intermediates/libfoo.a.
Bug: 11654773
Change-Id: I1d92733968fc442e9225b4df5bd1b551a81d89f7
This is the first step to build 32-bit libraries in a 64-bit product.
It will work like this:
1) In the product's BoardConfig.mk, define:
TARGET_2ND_ARCH, TARGET_2ND_ARCH_VARIANT, TARGET_2ND_CPU_VARIANT.
The build system uses those variables to set up an additional compiler
environment for the second arch.
2) When parsing Android.mks, the build system sets up rules to build a
module for both the 1st arch and the 2nd arch, unless it's explicitly
asked to skip so.
Android.mk will be adapted if there is additional rule of generating
source files.
The build system will accept arch-specific LOCAL_ variables, such as
LOCAL_CFLAGS_arm, LOCAL_CFLAGS_armv7-a-neon, LOCAL_CFLAGS_cortex-a15,
LOCAL_CFLAGS_aarch64 etc. Modules use such variables to set up build for
various archs at the same time.
3) Install binary of the 2nd arch by adding "<module_name>:32" to
PRODUCT_PACKAGES. All 2nd-arch libraries linked in by "<module_name>:32"
will be installed automatically.
Bug: 11654773
Change-Id: I2df63cd5463a07bf5358bee2a109f8fb9590fe30
_LARGEFILE_SOURCE should never be defined with bionic.
_FILE_OFFSET_BITS should be 64 on 64-bit architectures.
Change-Id: I7acf6b39a3af7782d5d7ad00f709593d96fa8522
All thumb code compiles with -fno-strict-aliasing. Let's not make aarch64
porting any more difficult than it needs to be.
Change-Id: I94874df1217b69532c328d7c86c9961631ebde8a
