tequilaOS/platform_build
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity
platform_build/core/combo/TARGET_linux-arm.mk

195 lines
8.3 KiB
Makefile
Raw Normal View History

Get rid of $(combo_target) The only OS-ARCH combo that would have benefited from it is linux-x86, but it explicitly used separate configurations for the HOST_ and TARGET_ side of things. This makes is clear which files are related to the HOST_ configuration and which ones are related to the TARGET_ configuration, and expands $(combo_target) to the only possible/reasonable value that it could have had in every file. This also cleans up the simulator, by moving it in a single place in TARGET_linux_x86 (since the only part that's special is to use HOST_ settings even when building TARGET_ modules). Change-Id: I2420eeb8cfe539f5807ec99cb3177ffb9f2476d5
2010-02-23 21:36:56 +01:00
#
# Copyright (C) 2006 The Android Open Source Project
#
# Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License.
# You may obtain a copy of the License at
#
# http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.
#
Initial Contribution
2008-10-21 16:00:00 +02:00
# Configuration for Linux on ARM.
Get rid of $(combo_target) The only OS-ARCH combo that would have benefited from it is linux-x86, but it explicitly used separate configurations for the HOST_ and TARGET_ side of things. This makes is clear which files are related to the HOST_ configuration and which ones are related to the TARGET_ configuration, and expands $(combo_target) to the only possible/reasonable value that it could have had in every file. This also cleans up the simulator, by moving it in a single place in TARGET_linux_x86 (since the only part that's special is to use HOST_ settings even when building TARGET_ modules). Change-Id: I2420eeb8cfe539f5807ec99cb3177ffb9f2476d5
2010-02-23 21:36:56 +01:00
# Included by combo/select.mk
Initial Contribution
2008-10-21 16:00:00 +02:00
Rename TARGET_ARCH_VERSION to TARGET_ARCH_VARIANT + Move arch-specific definitions into core/combo/arch/arm/<variant>.mk
2009-05-29 15:34:02 +02:00
# You can set TARGET_ARCH_VARIANT to use an arch version other
# than ARMv5TE. Each value should correspond to a file named
# $(BUILD_COMBOS)/arch/<name>.mk which must contain
# makefile variable definitions similar to the preprocessor
Move AndroidConfig.h from system/core to the build project. So unbundled branches don't need to include the system/core project. Change-Id: Ic4ef62ee6df069b9b2dd123aed95a3e7fcdfc146
2012-09-20 19:06:33 +02:00
# defines in build/core/combo/include/arch/<combo>/AndroidConfig.h. Their
Rename TARGET_ARCH_VERSION to TARGET_ARCH_VARIANT + Move arch-specific definitions into core/combo/arch/arm/<variant>.mk
2009-05-29 15:34:02 +02:00
# purpose is to allow module Android.mk files to selectively compile
# different versions of code based upon the funtionality and
This is the first set of build system changes to support architecture versions other than ARMv5TE. The general approach is to provide TARGET_ARCH_VERSION, to complement TARGET_ARCH. This defaults to the current armv5te. The variable values should match the architectures as defined by gcc. There is a block of defines for each supported architecture version (currently ARMv5TE and ARMv4). Each block defines a set of features using ARCH_ARM_HAVE_<x> variables. It also specifies a set of c preprocessor defines to pass to the compiler. Finally it defines a default CPU. (As for architecture versions, the default CPU should match a CPU that gcc knows about.) Support is added for architectures that do not support THUMB. Specifically we change the 'thumb compile' target to simply compile as ARM code instead, and we change the interworking flag passed to the compiler. Finally, we ensure that the system/core/include/arch/linux-arm directory is added to the default include path, which allows the use of asm/macros.h header file described in review #1626. The way in which this done is considerably unclean/hacky, if someone can suggest a better way please let me know.
2008-10-30 16:41:09 +01:00
# instructions available in a given architecture version.
#
Rename TARGET_ARCH_VERSION to TARGET_ARCH_VARIANT + Move arch-specific definitions into core/combo/arch/arm/<variant>.mk
2009-05-29 15:34:02 +02:00
# The blocks also define specific arch_variant_cflags, which
This is the first set of build system changes to support architecture versions other than ARMv5TE. The general approach is to provide TARGET_ARCH_VERSION, to complement TARGET_ARCH. This defaults to the current armv5te. The variable values should match the architectures as defined by gcc. There is a block of defines for each supported architecture version (currently ARMv5TE and ARMv4). Each block defines a set of features using ARCH_ARM_HAVE_<x> variables. It also specifies a set of c preprocessor defines to pass to the compiler. Finally it defines a default CPU. (As for architecture versions, the default CPU should match a CPU that gcc knows about.) Support is added for architectures that do not support THUMB. Specifically we change the 'thumb compile' target to simply compile as ARM code instead, and we change the interworking flag passed to the compiler. Finally, we ensure that the system/core/include/arch/linux-arm directory is added to the default include path, which allows the use of asm/macros.h header file described in review #1626. The way in which this done is considerably unclean/hacky, if someone can suggest a better way please let me know.
2008-10-30 16:41:09 +01:00
# include defines, and compiler settings for the given architecture
# version.
#
Load compiler environment for a second arch. 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
2013-12-27 20:09:36 +01:00
ifeq ($(strip $(TARGET_$(combo_2nd_arch_prefix)ARCH_VARIANT)),)
TARGET_$(combo_2nd_arch_prefix)ARCH_VARIANT := armv5te
This is the first set of build system changes to support architecture versions other than ARMv5TE. The general approach is to provide TARGET_ARCH_VERSION, to complement TARGET_ARCH. This defaults to the current armv5te. The variable values should match the architectures as defined by gcc. There is a block of defines for each supported architecture version (currently ARMv5TE and ARMv4). Each block defines a set of features using ARCH_ARM_HAVE_<x> variables. It also specifies a set of c preprocessor defines to pass to the compiler. Finally it defines a default CPU. (As for architecture versions, the default CPU should match a CPU that gcc knows about.) Support is added for architectures that do not support THUMB. Specifically we change the 'thumb compile' target to simply compile as ARM code instead, and we change the interworking flag passed to the compiler. Finally, we ensure that the system/core/include/arch/linux-arm directory is added to the default include path, which allows the use of asm/macros.h header file described in review #1626. The way in which this done is considerably unclean/hacky, if someone can suggest a better way please let me know.
2008-10-30 16:41:09 +01:00
endif
Rename TARGET_ARCH_VERSION to TARGET_ARCH_VARIANT + Move arch-specific definitions into core/combo/arch/arm/<variant>.mk
2009-05-29 15:34:02 +02:00
Decouple platform compiler and NDK library versioning. TARGET_GCC_VERSION: select compiler from prebuilts/gcc/... TARGET_NDK_GCC_VERSION: select libraries from prebuilts/ndk/... Change-Id: I4422a42cdc97aa92b40798014cba82c3c123bbd2
2014-04-11 07:46:26 +02:00
# Decouple NDK library selection with platform compiler version
$(combo_2nd_arch_prefix)TARGET_NDK_GCC_VERSION := 4.8
Enable lunch command to pick up new toolchain version. Otherwise the previously exported value will be sticky and the value defined in the TARGET makefile is ignored. Change-Id: Icdacb8c46034b8a24a9875b7596b31d00861512a
2012-12-13 01:22:54 +01:00
ifeq ($(strip $(TARGET_GCC_VERSION_EXP)),)
Load compiler environment for a second arch. 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
2013-12-27 20:09:36 +01:00
$(combo_2nd_arch_prefix)TARGET_GCC_VERSION := 4.8
Enable lunch command to pick up new toolchain version. Otherwise the previously exported value will be sticky and the value defined in the TARGET makefile is ignored. Change-Id: Icdacb8c46034b8a24a9875b7596b31d00861512a
2012-12-13 01:22:54 +01:00
else
Load compiler environment for a second arch. 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
2013-12-27 20:09:36 +01:00
$(combo_2nd_arch_prefix)TARGET_GCC_VERSION := $(TARGET_GCC_VERSION_EXP)
Define TARGET_GCC_VERSION in target specific make files. So that GCC refresh can be performed in a target specific way. Change-Id: I867e8b8fd671bef8c5af300e657a6da4fface032
2012-12-11 23:01:10 +01:00
endif
Load compiler environment for a second arch. 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
2013-12-27 20:09:36 +01:00
TARGET_ARCH_SPECIFIC_MAKEFILE := $(BUILD_COMBOS)/arch/$(TARGET_$(combo_2nd_arch_prefix)ARCH)/$(TARGET_$(combo_2nd_arch_prefix)ARCH_VARIANT).mk
Rename TARGET_ARCH_VERSION to TARGET_ARCH_VARIANT + Move arch-specific definitions into core/combo/arch/arm/<variant>.mk
2009-05-29 15:34:02 +02:00
ifeq ($(strip $(wildcard $(TARGET_ARCH_SPECIFIC_MAKEFILE))),)
Load compiler environment for a second arch. 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
2013-12-27 20:09:36 +01:00
$(error Unknown ARM architecture version: $(TARGET_$(combo_2nd_arch_prefix)ARCH_VARIANT))
Added support for TARGET_ARCH_VERSION=armv5te-vfp. This is currently a copy & paste of the armv5te parameters. I don't know if there's a better way to encode this, or to what extent we will need to specialize it vs. armv5te in a future build (e.g. to enable fp instruction use in code gen). Currently the only effect is to select the VFP-enabled mterp sources in Dalvik.
2009-05-28 21:47:23 +02:00
endif
This is the first set of build system changes to support architecture versions other than ARMv5TE. The general approach is to provide TARGET_ARCH_VERSION, to complement TARGET_ARCH. This defaults to the current armv5te. The variable values should match the architectures as defined by gcc. There is a block of defines for each supported architecture version (currently ARMv5TE and ARMv4). Each block defines a set of features using ARCH_ARM_HAVE_<x> variables. It also specifies a set of c preprocessor defines to pass to the compiler. Finally it defines a default CPU. (As for architecture versions, the default CPU should match a CPU that gcc knows about.) Support is added for architectures that do not support THUMB. Specifically we change the 'thumb compile' target to simply compile as ARM code instead, and we change the interworking flag passed to the compiler. Finally, we ensure that the system/core/include/arch/linux-arm directory is added to the default include path, which allows the use of asm/macros.h header file described in review #1626. The way in which this done is considerably unclean/hacky, if someone can suggest a better way please let me know.
2008-10-30 16:41:09 +01:00
Rename TARGET_ARCH_VERSION to TARGET_ARCH_VARIANT + Move arch-specific definitions into core/combo/arch/arm/<variant>.mk
2009-05-29 15:34:02 +02:00
include $(TARGET_ARCH_SPECIFIC_MAKEFILE)
Refactor FDO support code to ensure arm64 can also be built with FDO. Change-Id: I752c9f411b0a046a15c72b4837efc1fb0503b470
2014-07-23 23:28:58 +02:00
include $(BUILD_SYSTEM)/combo/fdo.mk
Rename TARGET_ARCH_VERSION to TARGET_ARCH_VARIANT + Move arch-specific definitions into core/combo/arch/arm/<variant>.mk
2009-05-29 15:34:02 +02:00
Initial Contribution
2008-10-21 16:00:00 +02:00
# You can set TARGET_TOOLS_PREFIX to get gcc from somewhere else
Load compiler environment for a second arch. 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
2013-12-27 20:09:36 +01:00
ifeq ($(strip $($(combo_2nd_arch_prefix)TARGET_TOOLS_PREFIX)),)
$(combo_2nd_arch_prefix)TARGET_TOOLCHAIN_ROOT := prebuilts/gcc/$(HOST_PREBUILT_TAG)/arm/arm-linux-androideabi-$($(combo_2nd_arch_prefix)TARGET_GCC_VERSION)
$(combo_2nd_arch_prefix)TARGET_TOOLS_PREFIX := $($(combo_2nd_arch_prefix)TARGET_TOOLCHAIN_ROOT)/bin/arm-linux-androideabi-
Initial Contribution
2008-10-21 16:00:00 +02:00
endif
Load compiler environment for a second arch. 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
2013-12-27 20:09:36 +01:00
$(combo_2nd_arch_prefix)TARGET_CC := $($(combo_2nd_arch_prefix)TARGET_TOOLS_PREFIX)gcc$(HOST_EXECUTABLE_SUFFIX)
$(combo_2nd_arch_prefix)TARGET_CXX := $($(combo_2nd_arch_prefix)TARGET_TOOLS_PREFIX)g++$(HOST_EXECUTABLE_SUFFIX)
$(combo_2nd_arch_prefix)TARGET_AR := $($(combo_2nd_arch_prefix)TARGET_TOOLS_PREFIX)ar$(HOST_EXECUTABLE_SUFFIX)
$(combo_2nd_arch_prefix)TARGET_OBJCOPY := $($(combo_2nd_arch_prefix)TARGET_TOOLS_PREFIX)objcopy$(HOST_EXECUTABLE_SUFFIX)
$(combo_2nd_arch_prefix)TARGET_LD := $($(combo_2nd_arch_prefix)TARGET_TOOLS_PREFIX)ld$(HOST_EXECUTABLE_SUFFIX)
Add a method to leave the symbol table in a library. When LOCAL_STRIP_MODULE := keep_symbols is set, then the normal strip rules will be modified so that only the .debug_* sections are removed. The original symbol table is left alone. This allows the compilation of certain libraries so that libbacktrace library can provide meaningful names to functions. Bug: 12958251 Change-Id: I82bdc304a463012e29086325ccb51163464cb4a9
2014-03-18 22:50:09 +01:00
$(combo_2nd_arch_prefix)TARGET_READELF := $($(combo_2nd_arch_prefix)TARGET_TOOLS_PREFIX)readelf$(HOST_EXECUTABLE_SUFFIX)
Load compiler environment for a second arch. 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
2013-12-27 20:09:36 +01:00
$(combo_2nd_arch_prefix)TARGET_STRIP := $($(combo_2nd_arch_prefix)TARGET_TOOLS_PREFIX)strip$(HOST_EXECUTABLE_SUFFIX)
Initial Contribution
2008-10-21 16:00:00 +02:00
Load compiler environment for a second arch. 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
2013-12-27 20:09:36 +01:00
$(combo_2nd_arch_prefix)TARGET_NO_UNDEFINED_LDFLAGS := -Wl,--no-undefined
Initial Contribution
2008-10-21 16:00:00 +02:00
Load compiler environment for a second arch. 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
2013-12-27 20:09:36 +01:00
$(combo_2nd_arch_prefix)TARGET_arm_CFLAGS := -O2 \
core: Don't debug native modules when TARGET_BUILD_TYPE==debug Don't make the simulator default to debug mode. Remove all global "debug" {C,CPP}FLAGS, which are no longer used.
2009-04-24 03:44:55 +02:00
-fomit-frame-pointer \
-fstrict-aliasing \
Remove global inline options. The purpose of removing global inline options is to give compiler the opportunity to do inline optimizations and inline tunings for Android native codes. By removing these global inline options now, the size of almost all native libraries are reduced. And there is no noticable performance degradation on webkit, gcstone and skia benchmarks. Change-Id: I31e71f51e4f29fa6286fddb89e9eab227581c7b3
2010-12-22 01:33:48 +01:00
-funswitch-loops
Initial Contribution
2008-10-21 16:00:00 +02:00
Remove more always-true ARCH_ARM_HAVE_ flags. All the remaining flags appear to be actually used. Change-Id: I0e3d84915487eda4f0e97809fc36624fef5f1848
2013-02-14 21:04:48 +01:00
# Modules can choose to compile some source as thumb.
Load compiler environment for a second arch. 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
2013-12-27 20:09:36 +01:00
$(combo_2nd_arch_prefix)TARGET_thumb_CFLAGS := -mthumb \
core: Don't debug native modules when TARGET_BUILD_TYPE==debug Don't make the simulator default to debug mode. Remove all global "debug" {C,CPP}FLAGS, which are no longer used.
2009-04-24 03:44:55 +02:00
-Os \
-fomit-frame-pointer \
Remove global inline options. The purpose of removing global inline options is to give compiler the opportunity to do inline optimizations and inline tunings for Android native codes. By removing these global inline options now, the size of almost all native libraries are reduced. And there is no noticable performance degradation on webkit, gcstone and skia benchmarks. Change-Id: I31e71f51e4f29fa6286fddb89e9eab227581c7b3
2010-12-22 01:33:48 +01:00
-fno-strict-aliasing
Initial Contribution
2008-10-21 16:00:00 +02:00
core: Don't debug native modules when TARGET_BUILD_TYPE==debug Don't make the simulator default to debug mode. Remove all global "debug" {C,CPP}FLAGS, which are no longer used.
2009-04-24 03:44:55 +02:00
# Set FORCE_ARM_DEBUGGING to "true" in your buildspec.mk
# or in your environment to force a full arm build, even for
# files that are normally built as thumb; this can make
# gdb debugging easier. Don't forget to do a clean build.
#
# NOTE: if you try to build a -O0 build with thumb, several
Initial Contribution
2008-10-21 16:00:00 +02:00
# of the libraries (libpv, libwebcore, libkjs) need to be built
# with -mlong-calls. When built at -O0, those libraries are
# too big for a thumb "BL <label>" to go from one end to the other.
core: Don't debug native modules when TARGET_BUILD_TYPE==debug Don't make the simulator default to debug mode. Remove all global "debug" {C,CPP}FLAGS, which are no longer used.
2009-04-24 03:44:55 +02:00
ifeq ($(FORCE_ARM_DEBUGGING),true)
Load compiler environment for a second arch. 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
2013-12-27 20:09:36 +01:00
$(combo_2nd_arch_prefix)TARGET_arm_CFLAGS += -fno-omit-frame-pointer -fno-strict-aliasing
$(combo_2nd_arch_prefix)TARGET_thumb_CFLAGS += -marm -fno-omit-frame-pointer
core: Don't debug native modules when TARGET_BUILD_TYPE==debug Don't make the simulator default to debug mode. Remove all global "debug" {C,CPP}FLAGS, which are no longer used.
2009-04-24 03:44:55 +02:00
endif
Initial Contribution
2008-10-21 16:00:00 +02:00
No need to filter out AndroidConfig.h for unbundled build for now we have all AndroidConfig.hs in the build project. Change-Id: Id713fecba1378fad81688f5937f61c779b618ac2
2013-08-15 20:01:10 +02:00
android_config_h := $(call select-android-config-h,linux-arm)
Load compiler environment for a second arch. 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
2013-12-27 20:09:36 +01:00
$(combo_2nd_arch_prefix)TARGET_GLOBAL_CFLAGS += \
Fix uses of -fPIC and -fPIE. 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
2014-08-06 21:36:46 +02:00
-msoft-float \
Initial Contribution
2008-10-21 16:00:00 +02:00
-ffunction-sections \
Enable ICF link-time optimization. Change-Id: I49af3366262bebe12dacfebe99ec742b79bf9d84
2010-06-29 20:14:42 +02:00
-fdata-sections \
Initial Contribution
2008-10-21 16:00:00 +02:00
-funwind-tables \
-fstack-protector \
Enable NX protections Add -Wa,--noexecstack and -Wl,-z,noexecstack as default flags when compiling applications. This enables NX protections, which prevent code from executing on the stack or heap. NX protections can block a large number of buffer overflow attacks, and is an important security feature. Change-Id: Iad4bab9f8664584ba6ce832a5318d07680d7a908
2010-05-05 20:09:52 +02:00
-Wa,--noexecstack \
Add -Werror=format-security Security hardening: don't allow code to compile which uses format strings in an inappropriate way. Make format string compiler warnings into errors. Change-Id: I1461dad589a2416420fd84ccf765983e859eea8a
2010-05-14 18:34:59 +02:00
-Werror=format-security \
arm: upgrade to _FORTIFY_SOURCE=2 Enable _FORTIFY_SOURCE=2 for ARM. Currently, this change is a no-op, as Android's libc doesn't support _FORTIFY_SOURCE > 1, yet. Change-Id: Ib4c8e44e6949a37352c153e3c52a4fa001f18738
2013-04-26 01:49:10 +02:00
-D_FORTIFY_SOURCE=2 \
auto import from //branches/cupcake/...@125939
2009-01-10 02:50:54 +01:00
-fno-short-enums \
Disable canonical prefixes of system headers GCC know a few pre-defined paths (relative to its location) to search for headers, libraries, program, etc. By default GCC prefixes its own path(argv[0]) and calls realpath() which result in absolute path with all symlink, . and .. removed. It's usually good to have canonicalised paths, but absolute paths in *.d file can cause unnecessary relinking when stale entries in ccache cache hit Add -no-canonical-prefixes (gcc>=4.6) and -fno-canonical-system-headers (gcc>4.6) to disable realpath() on prefixed paths Change-Id: I58d739e61fb013015fb05a9c98b2132b307f915a
2014-05-09 08:13:13 +02:00
-no-canonical-prefixes \
-fno-canonical-system-headers \
No need to filter out AndroidConfig.h for unbundled build for now we have all AndroidConfig.hs in the build project. Change-Id: Id713fecba1378fad81688f5937f61c779b618ac2
2013-08-15 20:01:10 +02:00
$(arch_variant_cflags) \
-include $(android_config_h) \
-I $(dir $(android_config_h))
This is the first set of build system changes to support architecture versions other than ARMv5TE. The general approach is to provide TARGET_ARCH_VERSION, to complement TARGET_ARCH. This defaults to the current armv5te. The variable values should match the architectures as defined by gcc. There is a block of defines for each supported architecture version (currently ARMv5TE and ARMv4). Each block defines a set of features using ARCH_ARM_HAVE_<x> variables. It also specifies a set of c preprocessor defines to pass to the compiler. Finally it defines a default CPU. (As for architecture versions, the default CPU should match a CPU that gcc knows about.) Support is added for architectures that do not support THUMB. Specifically we change the 'thumb compile' target to simply compile as ARM code instead, and we change the interworking flag passed to the compiler. Finally, we ensure that the system/core/include/arch/linux-arm directory is added to the default include path, which allows the use of asm/macros.h header file described in review #1626. The way in which this done is considerably unclean/hacky, if someone can suggest a better way please let me know.
2008-10-30 16:41:09 +01:00
Re-tighten default compiler options. Remove "-Wno-unused-parameter -Wno-unused-but-set-parameter" added for GCC 4.8 experiment. BUG: 10495043 Change-Id: I774deb09c782fe79eb473fdefd471725a1f97fd5
2013-08-28 20:00:54 +02:00
# The "-Wunused-but-set-variable" option often breaks projects that enable
# "-Wall -Werror" due to a commom idiom "ALOGV(mesg)" where ALOGV is turned
# into no-op in some builds while mesg is defined earlier. So we explicitly
# disable "-Wunused-but-set-variable" here.
Load compiler environment for a second arch. 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
2013-12-27 20:09:36 +01:00
ifneq ($(filter 4.6 4.6.% 4.7 4.7.% 4.8, $($(combo_2nd_arch_prefix)TARGET_GCC_VERSION)),)
$(combo_2nd_arch_prefix)TARGET_GLOBAL_CFLAGS += -fno-builtin-sin \
Re-tighten default compiler options. Remove "-Wno-unused-parameter -Wno-unused-but-set-parameter" added for GCC 4.8 experiment. BUG: 10495043 Change-Id: I774deb09c782fe79eb473fdefd471725a1f97fd5
2013-08-28 20:00:54 +02:00
-fno-strict-volatile-bitfields
Conditionally disable -Wno-unused-but-set-variable for gcc-4.6. We used to do that unconditionally but that caused lots of spurious warnings in gcc-4.4.x about an unrecognized gcc option. Change-Id: Idb5118b069871859e07a7efa04914ab6ed0b1372
2011-07-15 01:34:26 +02:00
endif
Remove irritating warnings about 'va_list' mangling when building C++ sources. Change-Id: I6305e93515e57462e7c57af0cc41a659e4190696
2010-06-17 01:04:55 +02:00
# This is to avoid the dreaded warning compiler message:
# note: the mangling of 'va_list' has changed in GCC 4.4
#
# The fact that the mangling changed does not affect the NDK ABI
# very fortunately (since none of the exposed APIs used va_list
# in their exported C++ functions). Also, GCC 4.5 has already
# removed the warning from the compiler.
#
Load compiler environment for a second arch. 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
2013-12-27 20:09:36 +01:00
$(combo_2nd_arch_prefix)TARGET_GLOBAL_CFLAGS += -Wno-psabi
Remove irritating warnings about 'va_list' mangling when building C++ sources. Change-Id: I6305e93515e57462e7c57af0cc41a659e4190696
2010-06-17 01:04:55 +02:00
Load compiler environment for a second arch. 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
2013-12-27 20:09:36 +01:00
$(combo_2nd_arch_prefix)TARGET_GLOBAL_LDFLAGS += \
Enable NX protections Add -Wa,--noexecstack and -Wl,-z,noexecstack as default flags when compiling applications. This enables NX protections, which prevent code from executing on the stack or heap. NX protections can block a large number of buffer overflow attacks, and is an important security feature. Change-Id: Iad4bab9f8664584ba6ce832a5318d07680d7a908
2010-05-05 20:09:52 +02:00
-Wl,-z,noexecstack \
ARM: compile everything with relro / bind_now. Enable relro / bind_now when compiling Android applications. This marks certain regions of memory as read-only after linking, making memory corruption security vulnerabilities are harder to exploit. See: * http://www.akkadia.org/drepper/nonselsec.pdf (section 6) * http://tk-blog.blogspot.com/2009/02/relro-not-so-well-known-memory.html Stop using the custom linker script, which inhibits relro / bind_now support. Change-Id: Ie97ccdd2845886bbc2ba2fdd47eed0ff4b29b60b
2012-04-26 18:09:24 +02:00
-Wl,-z,relro \
-Wl,-z,now \
arm: add --warn-shared-textrel Emit a warning when the static linker detects a shared library has text relocations. Text relocations make it harder to share pages across processes, and make it harder to use certain memory protection features in, for example, SELinux. This warning will turn into an error in a future change (via --fatal-warnings) References: http://www.akkadia.org/drepper/textrelocs.html Change-Id: I3bc818e3ecdb8a4338668a9e816b6dc1081b7557
2012-08-10 21:51:26 +02:00
-Wl,--warn-shared-textrel \
arm: turn on -Wl,--fatal-warnings Third time's the charm. :-) In b238210c0172e771b1302364273016ad1fabafb8, we added -Wl,--warn-shared-textrel to TARGET_GLOBAL_LDFLAGS. This generated a warning whenever we created a shared library with a text relocation. At the time, we wrote: ===== Emit a warning when the static linker detects a shared library has text relocations. Text relocations make it harder to share pages across processes, and make it harder to use certain memory protection features in, for example, SELinux. This warning will turn into an error in a future change (via --fatal-warnings) ===== All code which uses text relocations has either been fixed, or we've temporarily worked around the issue so the code can still compile. Enable --fatal-warnings. This reverts commit 942167dab8345c420b205ce9b9b6b4fc779a7583. Change-Id: I578701692ead7e7cd60d73d2070a5bed366e2c6c
2012-10-18 23:21:26 +02:00
-Wl,--fatal-warnings \
Enable ICF link-time optimization. Change-Id: I49af3366262bebe12dacfebe99ec742b79bf9d84
2010-06-29 20:14:42 +02:00
-Wl,--icf=safe \
Switch --hash-style to gnu Bug: 18373609 Change-Id: Ia2c965fb86295858d9a97db2ec8d54d99e3d431f
2014-11-13 23:51:10 +01:00
-Wl,--hash-style=gnu \
enable cortex branch predition errata workaround for armv7-a builds Signed-off-by: Erik Gilling <konkers@android.com>
2009-07-18 00:57:10 +02:00
$(arch_variant_ldflags)
Load compiler environment for a second arch. 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
2013-12-27 20:09:36 +01:00
$(combo_2nd_arch_prefix)TARGET_GLOBAL_CFLAGS += -mthumb-interwork
Initial Contribution
2008-10-21 16:00:00 +02:00
Load compiler environment for a second arch. 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
2013-12-27 20:09:36 +01:00
$(combo_2nd_arch_prefix)TARGET_GLOBAL_CPPFLAGS += -fvisibility-inlines-hidden
Initial Contribution
2008-10-21 16:00:00 +02:00
Insert directives to work around a CPU bug. Bug: 3117632 Change-Id: I2fb58e7093984d18d2d2d21edf687206f4ddab31
2010-10-22 00:15:09 +02:00
# More flags/options can be added here
Load compiler environment for a second arch. 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
2013-12-27 20:09:36 +01:00
$(combo_2nd_arch_prefix)TARGET_RELEASE_CFLAGS := \
remove reference to SK_RELEASE, since that is automatically set based on NDEBUG (or its absence) i.e. if NDEBUG is defined, then SK_RELEASE will get defined in the skia config headers
2009-10-30 13:32:28 +01:00
-DNDEBUG \
auto import from //depot/cupcake/@136594
2009-03-05 23:34:30 +01:00
-g \
Initial Contribution
2008-10-21 16:00:00 +02:00
-Wstrict-aliasing=2 \
-fgcse-after-reload \
-frerun-cse-after-loop \
-frename-registers
libc_root := bionic/libc
libm_root := bionic/libm
This is the first set of build system changes to support architecture versions other than ARMv5TE. The general approach is to provide TARGET_ARCH_VERSION, to complement TARGET_ARCH. This defaults to the current armv5te. The variable values should match the architectures as defined by gcc. There is a block of defines for each supported architecture version (currently ARMv5TE and ARMv4). Each block defines a set of features using ARCH_ARM_HAVE_<x> variables. It also specifies a set of c preprocessor defines to pass to the compiler. Finally it defines a default CPU. (As for architecture versions, the default CPU should match a CPU that gcc knows about.) Support is added for architectures that do not support THUMB. Specifically we change the 'thumb compile' target to simply compile as ARM code instead, and we change the interworking flag passed to the compiler. Finally, we ensure that the system/core/include/arch/linux-arm directory is added to the default include path, which allows the use of asm/macros.h header file described in review #1626. The way in which this done is considerably unclean/hacky, if someone can suggest a better way please let me know.
2008-10-30 16:41:09 +01:00
## on some hosts, the target cross-compiler is not available so do not run this command
Load compiler environment for a second arch. 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
2013-12-27 20:09:36 +01:00
ifneq ($(wildcard $($(combo_2nd_arch_prefix)TARGET_CC)),)
Rename TARGET_ARCH_VERSION to TARGET_ARCH_VARIANT + Move arch-specific definitions into core/combo/arch/arm/<variant>.mk
2009-05-29 15:34:02 +02:00
# We compile with the global cflags to ensure that
This is the first set of build system changes to support architecture versions other than ARMv5TE. The general approach is to provide TARGET_ARCH_VERSION, to complement TARGET_ARCH. This defaults to the current armv5te. The variable values should match the architectures as defined by gcc. There is a block of defines for each supported architecture version (currently ARMv5TE and ARMv4). Each block defines a set of features using ARCH_ARM_HAVE_<x> variables. It also specifies a set of c preprocessor defines to pass to the compiler. Finally it defines a default CPU. (As for architecture versions, the default CPU should match a CPU that gcc knows about.) Support is added for architectures that do not support THUMB. Specifically we change the 'thumb compile' target to simply compile as ARM code instead, and we change the interworking flag passed to the compiler. Finally, we ensure that the system/core/include/arch/linux-arm directory is added to the default include path, which allows the use of asm/macros.h header file described in review #1626. The way in which this done is considerably unclean/hacky, if someone can suggest a better way please let me know.
2008-10-30 16:41:09 +01:00
# any flags which affect libgcc are correctly taken
# into account.
Load compiler environment for a second arch. 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
2013-12-27 20:09:36 +01:00
$(combo_2nd_arch_prefix)TARGET_LIBGCC := $(shell $($(combo_2nd_arch_prefix)TARGET_CC) \
$($(combo_2nd_arch_prefix)TARGET_GLOBAL_CFLAGS) -print-libgcc-file-name)
Add -latomic to all target builds 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
2014-05-29 11:47:27 +02:00
$(combo_2nd_arch_prefix)TARGET_LIBATOMIC := $(shell $($(combo_2nd_arch_prefix)TARGET_CC) \
$($(combo_2nd_arch_prefix)TARGET_GLOBAL_CFLAGS) -print-file-name=libatomic.a)
resolved conflicts for merge of 326f9450 to lmp-dev-plus-aosp Change-Id: I66360da623a6e7ac04610c3252f24ed69f7e4b1e
2014-09-24 18:42:39 +02:00
$(combo_2nd_arch_prefix)TARGET_LIBGCOV := $(shell $($(combo_2nd_arch_prefix)TARGET_CC) \
$($(combo_2nd_arch_prefix)TARGET_GLOBAL_CFLAGS) -print-file-name=libgcov.a)
This is the first set of build system changes to support architecture versions other than ARMv5TE. The general approach is to provide TARGET_ARCH_VERSION, to complement TARGET_ARCH. This defaults to the current armv5te. The variable values should match the architectures as defined by gcc. There is a block of defines for each supported architecture version (currently ARMv5TE and ARMv4). Each block defines a set of features using ARCH_ARM_HAVE_<x> variables. It also specifies a set of c preprocessor defines to pass to the compiler. Finally it defines a default CPU. (As for architecture versions, the default CPU should match a CPU that gcc knows about.) Support is added for architectures that do not support THUMB. Specifically we change the 'thumb compile' target to simply compile as ARM code instead, and we change the interworking flag passed to the compiler. Finally, we ensure that the system/core/include/arch/linux-arm directory is added to the default include path, which allows the use of asm/macros.h header file described in review #1626. The way in which this done is considerably unclean/hacky, if someone can suggest a better way please let me know.
2008-10-30 16:41:09 +01:00
endif
Remove obsolete CUSTOM_KERNEL_HEADERS. Change-Id: Id260dd351b90f065eee56e231d4c341b18c1b27f
2014-01-11 01:35:08 +01:00
KERNEL_HEADERS_COMMON := $(libc_root)/kernel/uapi
build: use arm kernel headers for arm 2nd arch builds 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
2014-01-22 01:54:00 +01:00
KERNEL_HEADERS_ARCH := $(libc_root)/kernel/uapi/asm-$(TARGET_$(combo_2nd_arch_prefix)ARCH)
Re-enable uapi kernel headers for arm. Bug: 11559337 Change-Id: Ib914e5f22b10d5a74edc357d42b0dcb223185ab4
2013-12-16 22:58:39 +01:00
KERNEL_HEADERS := $(KERNEL_HEADERS_COMMON) $(KERNEL_HEADERS_ARCH)
Initial Contribution
2008-10-21 16:00:00 +02:00
Load compiler environment for a second arch. 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
2013-12-27 20:09:36 +01:00
$(combo_2nd_arch_prefix)TARGET_C_INCLUDES := \
Initial Contribution
2008-10-21 16:00:00 +02:00
$(libc_root)/arch-arm/include \
$(libc_root)/include \
$(KERNEL_HEADERS) \
$(libm_root)/include \
core: fix paths to libm arch-specific include dirs Change-Id: I17a1ed13af6d4955a636ad429917b683ac59a947 Signed-off-by: Dima Zavin <dima@android.com>
2010-08-06 02:46:47 +02:00
$(libm_root)/include/arm \
Initial Contribution
2008-10-21 16:00:00 +02:00
Load compiler environment for a second arch. 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
2013-12-27 20:09:36 +01:00
$(combo_2nd_arch_prefix)TARGET_CRTBEGIN_STATIC_O := $($(combo_2nd_arch_prefix)TARGET_OUT_INTERMEDIATE_LIBRARIES)/crtbegin_static.o
$(combo_2nd_arch_prefix)TARGET_CRTBEGIN_DYNAMIC_O := $($(combo_2nd_arch_prefix)TARGET_OUT_INTERMEDIATE_LIBRARIES)/crtbegin_dynamic.o
$(combo_2nd_arch_prefix)TARGET_CRTEND_O := $($(combo_2nd_arch_prefix)TARGET_OUT_INTERMEDIATE_LIBRARIES)/crtend_android.o
Initial Contribution
2008-10-21 16:00:00 +02:00
Load compiler environment for a second arch. 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
2013-12-27 20:09:36 +01:00
$(combo_2nd_arch_prefix)TARGET_CRTBEGIN_SO_O := $($(combo_2nd_arch_prefix)TARGET_OUT_INTERMEDIATE_LIBRARIES)/crtbegin_so.o
$(combo_2nd_arch_prefix)TARGET_CRTEND_SO_O := $($(combo_2nd_arch_prefix)TARGET_OUT_INTERMEDIATE_LIBRARIES)/crtend_so.o
Enable shared libraries to use crtbegin_so.S and crtend_so.S This is necessary to ensure that dlclose() will properly call C++ destructors for the static objects within the shared library. Change-Id: Ieb056042f9cda7ab120eb770b21f365cd6d64a66
2010-06-19 00:05:01 +02:00
Load compiler environment for a second arch. 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
2013-12-27 20:09:36 +01:00
$(combo_2nd_arch_prefix)TARGET_STRIP_MODULE:=true
Initial Contribution
2008-10-21 16:00:00 +02:00
Move selection of C++ STL into the build system. 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
2014-09-12 23:46:57 +02:00
$(combo_2nd_arch_prefix)TARGET_DEFAULT_SYSTEM_SHARED_LIBRARIES := libc libm
Initial Contribution
2008-10-21 16:00:00 +02:00
Refactor transform-o-to-* definitions. Previously, there was one generic definition for each of the transform-o-to-* functions in definitions.mk, and one target specific one in each combo/TARGET_*.mk. The generic one was entirely unused, and the target specific ones were all nearly identical. Changing anything in these functions was tedious at best, and often error prone. The differences between any 32-bit arch and its 64-bit equivalent were restricted to the name of the linker, and the ARM and MIPS definitions were identical. The few differences between ARM and x86 looked to be compatibility for an old (ca. 2008) toolchain issue with --gc-sections, and a bug (LDFLAGS coming first rather than later). To simplify things, I've moved the definitions for these out of combo/TARGET_*.mk and back into definitions.mk. The differences between ARM and x86 have been scrapped. Anything that really does still need to be target specific can be handled as I have the linker: add a TARGET_FOO variable to the given target and then add it to the generic definition. Change-Id: I54dc1bffc32ac39f27f0b87247dd6a6dbaf0b162
2014-11-13 19:15:46 +01:00
$(combo_2nd_arch_prefix)TARGET_LINKER := /system/bin/linker
Reference in a new issue Copy permalink