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

295 lines
12 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 Conflicts: core/combo/TARGET_linux-arm.mk
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
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 Conflicts: core/combo/TARGET_linux-arm.mk
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 Conflicts: core/combo/TARGET_linux-arm.mk
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 Conflicts: core/combo/TARGET_linux-arm.mk
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 Conflicts: core/combo/TARGET_linux-arm.mk
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)
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 Conflicts: core/combo/TARGET_linux-arm.mk
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 Conflicts: core/combo/TARGET_linux-arm.mk
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)
$(combo_2nd_arch_prefix)TARGET_STRIP := $($(combo_2nd_arch_prefix)TARGET_TOOLS_PREFIX)strip$(HOST_EXECUTABLE_SUFFIX)
Don't fall back to host $(CC) if the target gcc is not checked out Error "cc1plus: error: unrecognized command line option ‘-mfloat-abi=softfp’" is much more confusing than "...gcc: No such file or directory". Also we don't build in Windows/Cygwin any more so we don't need the old trick. Change-Id: Ibbe3da67b412575e56bd6e61ef412ea5b2789fea
2013-01-30 19:25:38 +01:00
ifeq ($(TARGET_BUILD_VARIANT),user)
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 Conflicts: core/combo/TARGET_linux-arm.mk
2013-12-27 20:09:36 +01:00
$(combo_2nd_arch_prefix)TARGET_STRIP_COMMAND = $(PRIVATE_STRIP) --strip-all $< -o $@
Don't fall back to host $(CC) if the target gcc is not checked out Error "cc1plus: error: unrecognized command line option ‘-mfloat-abi=softfp’" is much more confusing than "...gcc: No such file or directory". Also we don't build in Windows/Cygwin any more so we don't need the old trick. Change-Id: Ibbe3da67b412575e56bd6e61ef412ea5b2789fea
2013-01-30 19:25:38 +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 Conflicts: core/combo/TARGET_linux-arm.mk
2013-12-27 20:09:36 +01:00
$(combo_2nd_arch_prefix)TARGET_STRIP_COMMAND = $(PRIVATE_STRIP) --strip-all $< -o $@ && \
$(PRIVATE_OBJCOPY) --add-gnu-debuglink=$< $@
Lunch: don't use a toolchain that doesn't exist. "lunch sdk-eng" on cygwin tries to use a gcc.exe from the prebuild arm toolchain, but it doesn't exist. This prevents from setting variables to point on a gcc toolchain if there is none for the given arch. Change-Id: I3b72220663687f9fdaacc050899aef00632f2c3c
2011-06-21 02:25:01 +02:00
endif
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 Conflicts: core/combo/TARGET_linux-arm.mk
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 Conflicts: core/combo/TARGET_linux-arm.mk
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 Conflicts: core/combo/TARGET_linux-arm.mk
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 Conflicts: core/combo/TARGET_linux-arm.mk
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 Conflicts: core/combo/TARGET_linux-arm.mk
2013-12-27 20:09:36 +01:00
$(combo_2nd_arch_prefix)TARGET_GLOBAL_CFLAGS += \
enable PIE for dynamically linked executables Compile all programs on Android with -fPIE and -pie. This enables PIE (Position Independent Executables), which helps protect Android applications from exploitation due to memory management bugs. Stop using the armelf.x linker script. This script hard codes the load address of the executable, defeating the position independence PIE requires. Note: PIE *static* executables are not supported at this time and require additional linker changes. Bug: 5323301 Change-Id: Ieafcc9c4f142495847e163881889d371a59d0878
2011-10-24 19:53:36 +02:00
-msoft-float -fpic -fPIE \
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 \
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 (cherry picked from internal master 1cea0755f400c1d183d22679d5b931c3a04ae4a4) Change-Id: Ifa221709b1351a9268c06872e2b667138995c3da
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 Conflicts: core/combo/TARGET_linux-arm.mk
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 += -Wno-unused-but-set-variable -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 (cherry picked from internal master 1cea0755f400c1d183d22679d5b931c3a04ae4a4) Change-Id: Ifa221709b1351a9268c06872e2b667138995c3da
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 Conflicts: core/combo/TARGET_linux-arm.mk
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 Conflicts: core/combo/TARGET_linux-arm.mk
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 \
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 Conflicts: core/combo/TARGET_linux-arm.mk
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 Conflicts: core/combo/TARGET_linux-arm.mk
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 Conflicts: core/combo/TARGET_linux-arm.mk
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
libstdc++_root := bionic/libstdc++
libthread_db_root := bionic/libthread_db
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 Conflicts: core/combo/TARGET_linux-arm.mk
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 Conflicts: core/combo/TARGET_linux-arm.mk
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)
target_libgcov := $(shell $($(combo_2nd_arch_prefix)TARGET_CC) $($(combo_2nd_arch_prefix)TARGET_GLOBAL_CFLAGS) \
Don't fall back to host $(CC) if the target gcc is not checked out Error "cc1plus: error: unrecognized command line option ‘-mfloat-abi=softfp’" is much more confusing than "...gcc: No such file or directory". Also we don't build in Windows/Cygwin any more so we don't need the old trick. Change-Id: Ibbe3da67b412575e56bd6e61ef412ea5b2789fea
2013-01-30 19:25:38 +01:00
-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
Add FDO options to Android make system.
2009-09-22 01:31:50 +02:00
# Define FDO (Feedback Directed Optimization) options.
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 Conflicts: core/combo/TARGET_linux-arm.mk
2013-12-27 20:09:36 +01:00
$(combo_2nd_arch_prefix)TARGET_FDO_CFLAGS:=
$(combo_2nd_arch_prefix)TARGET_FDO_LIB:=
Add FDO options to Android make system.
2009-09-22 01:31:50 +02:00
ifneq ($(strip $(BUILD_FDO_INSTRUMENT)),)
# Set BUILD_FDO_INSTRUMENT=true to turn on FDO instrumentation.
# The profile will be generated on /data/local/tmp/profile on the device.
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 Conflicts: core/combo/TARGET_linux-arm.mk
2013-12-27 20:09:36 +01:00
$(combo_2nd_arch_prefix)TARGET_FDO_CFLAGS := -fprofile-generate=/data/local/tmp/profile -DANDROID_FDO
$(combo_2nd_arch_prefix)TARGET_FDO_LIB := $(target_libgcov)
Add FDO options to Android make system.
2009-09-22 01:31:50 +02:00
else
# If BUILD_FDO_INSTRUMENT is turned off, then consider doing the FDO optimizations.
# Set TARGET_FDO_PROFILE_PATH to set a custom profile directory for your build.
ifeq ($(strip $(TARGET_FDO_PROFILE_PATH)),)
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 Conflicts: core/combo/TARGET_linux-arm.mk
2013-12-27 20:09:36 +01:00
$(combo_2nd_arch_prefix)TARGET_FDO_PROFILE_PATH := fdo/profiles/$(TARGET_$(combo_2nd_arch_prefix)ARCH)/$(TARGET_$(combo_2nd_arch_prefix)ARCH_VARIANT)
Add FDO options to Android make system.
2009-09-22 01:31:50 +02: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 Conflicts: core/combo/TARGET_linux-arm.mk
2013-12-27 20:09:36 +01:00
ifeq ($(strip $(wildcard $($(combo_2nd_arch_prefix)TARGET_FDO_PROFILE_PATH))),)
$(warning Custom $(combo_2nd_arch_prefix)TARGET_FDO_PROFILE_PATH supplied, but directory does not exist. Turn off FDO.)
Add FDO options to Android make system.
2009-09-22 01:31:50 +02:00
endif
endif
# If the FDO profile directory can't be found, then FDO is off.
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 Conflicts: core/combo/TARGET_linux-arm.mk
2013-12-27 20:09:36 +01:00
ifneq ($(strip $(wildcard $($(combo_2nd_arch_prefix)TARGET_FDO_PROFILE_PATH))),)
$(combo_2nd_arch_prefix)TARGET_FDO_CFLAGS := -fprofile-use=$($(combo_2nd_arch_prefix)TARGET_FDO_PROFILE_PATH) -DANDROID_FDO
$(combo_2nd_arch_prefix)TARGET_FDO_LIB := $(target_libgcov)
Add FDO options to Android make system.
2009-09-22 01:31:50 +02:00
endif
endif
Remove obsolete CUSTOM_KERNEL_HEADERS. Change-Id: Id260dd351b90f065eee56e231d4c341b18c1b27f
2014-01-11 01:35:08 +01:00
KERNEL_HEADERS_COMMON := $(libc_root)/kernel/uapi
KERNEL_HEADERS_ARCH := $(libc_root)/kernel/uapi/asm-$(TARGET_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 Conflicts: core/combo/TARGET_linux-arm.mk
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 \
$(libstdc++_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
$(libthread_db_root)/include
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 Conflicts: core/combo/TARGET_linux-arm.mk
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 Conflicts: core/combo/TARGET_linux-arm.mk
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 Conflicts: core/combo/TARGET_linux-arm.mk
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
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 Conflicts: core/combo/TARGET_linux-arm.mk
2013-12-27 20:09:36 +01:00
$(combo_2nd_arch_prefix)TARGET_DEFAULT_SYSTEM_SHARED_LIBRARIES := libc libstdc++ libm
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 Conflicts: core/combo/TARGET_linux-arm.mk
2013-12-27 20:09:36 +01:00
$(combo_2nd_arch_prefix)TARGET_CUSTOM_LD_COMMAND := true
Enable Dalvik JIT by default for the master branch.
2009-09-09 01:31: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 Conflicts: core/combo/TARGET_linux-arm.mk
2013-12-27 20:09:36 +01:00
define $(combo_2nd_arch_prefix)transform-o-to-shared-lib-inner
Unify use of $(hide). Change-Id: Ib7e17bbb4682caecce5812e63de872b676403d64
2011-01-28 23:14:47 +01:00
$(hide) $(PRIVATE_CXX) \
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
-nostdlib -Wl,-soname,$(notdir $@) \
Initial Contribution
2008-10-21 16:00:00 +02:00
-Wl,--gc-sections \
-Wl,-shared,-Bsymbolic \
Support to build native libraries with prebuilt NDK Bug: http://b/issue?id=2811253 Change-Id: Iabd4ab8b3d7236dffe89f1939e1142e882944026
2010-07-13 23:55:47 +02:00
$(PRIVATE_TARGET_GLOBAL_LD_DIRS) \
Build system tweaks for Valgrind. Added LOCAL_NO_CRT to enable building executables that do not link to the C runtime library. Removed support for LOCAL_MODULE_SUBDIR since it was broken and unused. (Was going to use it but ended up using LOCAL_MODULE_PATH instead.) Change-Id: I3b6f5ab7e5ae6aaa7119899adccece2b4ab1cbb3
2011-02-05 05:15:00 +01:00
$(if $(filter true,$(PRIVATE_NO_CRT)),,$(PRIVATE_TARGET_CRTBEGIN_SO_O)) \
ARM: put crtbegin_so.o at the beginning where it belongs Change-Id: I9466fe9277c58a7b8f8a9964b2d578a65e579995
2012-08-21 10:42:32 +02:00
$(PRIVATE_ALL_OBJECTS) \
Initial Contribution
2008-10-21 16:00:00 +02:00
-Wl,--whole-archive \
Correct misuse of target/host vars. Change-Id: Ide41aeddc44ca05d85a36035c2d55ea453cfd216
2011-01-25 08:25:36 +01:00
$(call normalize-target-libraries,$(PRIVATE_ALL_WHOLE_STATIC_LIBRARIES)) \
Initial Contribution
2008-10-21 16:00:00 +02:00
-Wl,--no-whole-archive \
Add LOCAL_GROUP_STATIC_LIBRARIES Set LOCAL_GROUP_STATIC_LIBRARIES := true to group the static libraries, in case we need gcc flags "-Wl,--start-group" and "-Wl,--end-group" to fix circular references. Change-Id: I03c4901670112fcdd2bb0fe660b6924e5776fcf8
2011-04-25 23:22:41 +02:00
$(if $(PRIVATE_GROUP_STATIC_LIBRARIES),-Wl$(comma)--start-group) \
Initial Contribution
2008-10-21 16:00:00 +02:00
$(call normalize-target-libraries,$(PRIVATE_ALL_STATIC_LIBRARIES)) \
Add LOCAL_GROUP_STATIC_LIBRARIES Set LOCAL_GROUP_STATIC_LIBRARIES := true to group the static libraries, in case we need gcc flags "-Wl,--start-group" and "-Wl,--end-group" to fix circular references. Change-Id: I03c4901670112fcdd2bb0fe660b6924e5776fcf8
2011-04-25 23:22:41 +02:00
$(if $(PRIVATE_GROUP_STATIC_LIBRARIES),-Wl$(comma)--end-group) \
Add extra libgcc.a only for unbundled build. We can save some space for platform build with this. Previously an extra libgcc.a was put before libc.so so libraries built against new platform can run on old platforms. This is needed only for unbundled build. Bug: 8805022 Bug: 8247455 Change-Id: I3c3e0092b06ec3804659d5cae048d29e0d2bf7ad
2013-05-03 23:12:31 +02:00
$(if $(TARGET_BUILD_APPS),$(PRIVATE_TARGET_LIBGCC)) \
Link PRIVATE_TARGET_FDO_LIB before shared libraries For global declaration of FDO profile generation and usage, we need to link PRIVATE_TARGET_FDO_LIB (libgcov.a by default) prior to linking shared libraries. TARGET_FDO_LIB is set if feedback directed optimizations are in use, so we do not need to worry about consistent size increases from this change. Change-Id: I543903f58893816f037c9466f31b19dfe822fdf4
2013-08-07 09:00:39 +02:00
$(PRIVATE_TARGET_FDO_LIB) \
Initial Contribution
2008-10-21 16:00:00 +02:00
$(call normalize-target-libraries,$(PRIVATE_ALL_SHARED_LIBRARIES)) \
-o $@ \
Support to build native libraries with prebuilt NDK Bug: http://b/issue?id=2811253 Change-Id: Iabd4ab8b3d7236dffe89f1939e1142e882944026
2010-07-13 23:55:47 +02:00
$(PRIVATE_TARGET_GLOBAL_LDFLAGS) \
LOCAL_LDFLAGS should come after TARGET_GLOBAL_LDFLAGS A package can define a LOCAL_LDFLAGS. If a LOCAL_LDFLAGS exists, it should come after the global LDFLAGS, to allow the local flags to override the global flags. Change-Id: I6e44c17949c1f11c808d0ed3f327d63fb51a1468
2010-04-26 23:12:19 +02:00
$(PRIVATE_LDFLAGS) \
resolved conflicts for merge of 1a08100f to gingerbread Change-Id: I9e4183a1d5c0efb13de8655b9eb7c74d50b34cd7
2010-07-14 02:21:33 +02:00
$(PRIVATE_TARGET_LIBGCC) \
Build system tweaks for Valgrind. Added LOCAL_NO_CRT to enable building executables that do not link to the C runtime library. Removed support for LOCAL_MODULE_SUBDIR since it was broken and unused. (Was going to use it but ended up using LOCAL_MODULE_PATH instead.) Change-Id: I3b6f5ab7e5ae6aaa7119899adccece2b4ab1cbb3
2011-02-05 05:15:00 +01:00
$(if $(filter true,$(PRIVATE_NO_CRT)),,$(PRIVATE_TARGET_CRTEND_SO_O))
Initial Contribution
2008-10-21 16:00:00 +02:00
endef
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 Conflicts: core/combo/TARGET_linux-arm.mk
2013-12-27 20:09:36 +01:00
define $(combo_2nd_arch_prefix)transform-o-to-executable-inner
enable PIE for dynamically linked executables Compile all programs on Android with -fPIE and -pie. This enables PIE (Position Independent Executables), which helps protect Android applications from exploitation due to memory management bugs. Stop using the armelf.x linker script. This script hard codes the load address of the executable, defeating the position independence PIE requires. Note: PIE *static* executables are not supported at this time and require additional linker changes. Bug: 5323301 Change-Id: Ieafcc9c4f142495847e163881889d371a59d0878
2011-10-24 19:53:36 +02:00
$(hide) $(PRIVATE_CXX) -nostdlib -Bdynamic -fPIE -pie \
Initial Contribution
2008-10-21 16:00:00 +02:00
-Wl,-dynamic-linker,/system/bin/linker \
Don't include system/core/include/arch/<arch>/Android.mk for apps-only build. Bug: 6994483 Change-Id: I76c4d96264cf94a79d59fdeb52bb37c07a9458dd
2012-08-17 01:45:01 +02:00
-Wl,--gc-sections \
Initial Contribution
2008-10-21 16:00:00 +02:00
-Wl,-z,nocopyreloc \
Support to build executables against the NDK Use "LOCAL_SDK_VERSION := <number>" to build against the NDK when you include $(BUILD_EXECUTABLE). Bug: 7170098 Change-Id: I4cebeae3355e79a4d2f2f5549ef0613ced77e3f0
2012-09-26 02:52:10 +02:00
$(PRIVATE_TARGET_GLOBAL_LD_DIRS) \
Initial Contribution
2008-10-21 16:00:00 +02:00
-Wl,-rpath-link=$(TARGET_OUT_INTERMEDIATE_LIBRARIES) \
Support to build executables against the NDK Use "LOCAL_SDK_VERSION := <number>" to build against the NDK when you include $(BUILD_EXECUTABLE). Bug: 7170098 Change-Id: I4cebeae3355e79a4d2f2f5549ef0613ced77e3f0
2012-09-26 02:52:10 +02:00
$(if $(filter true,$(PRIVATE_NO_CRT)),,$(PRIVATE_TARGET_CRTBEGIN_DYNAMIC_O)) \
Initial Contribution
2008-10-21 16:00:00 +02:00
$(PRIVATE_ALL_OBJECTS) \
Update build rule for executable with PRIVATE_ALL_WHOLE_STATIC_LIBRARIES Change-Id: I9ff53f51dcb57511a24765bdf6a61c000a7ce977 Signed-off-by: Kito Cheng <kito@0xlab.org>
2012-01-20 12:21:46 +01:00
-Wl,--whole-archive \
$(call normalize-target-libraries,$(PRIVATE_ALL_WHOLE_STATIC_LIBRARIES)) \
-Wl,--no-whole-archive \
Add LOCAL_GROUP_STATIC_LIBRARIES Set LOCAL_GROUP_STATIC_LIBRARIES := true to group the static libraries, in case we need gcc flags "-Wl,--start-group" and "-Wl,--end-group" to fix circular references. Change-Id: I03c4901670112fcdd2bb0fe660b6924e5776fcf8
2011-04-25 23:22:41 +02:00
$(if $(PRIVATE_GROUP_STATIC_LIBRARIES),-Wl$(comma)--start-group) \
Initial Contribution
2008-10-21 16:00:00 +02:00
$(call normalize-target-libraries,$(PRIVATE_ALL_STATIC_LIBRARIES)) \
Add LOCAL_GROUP_STATIC_LIBRARIES Set LOCAL_GROUP_STATIC_LIBRARIES := true to group the static libraries, in case we need gcc flags "-Wl,--start-group" and "-Wl,--end-group" to fix circular references. Change-Id: I03c4901670112fcdd2bb0fe660b6924e5776fcf8
2011-04-25 23:22:41 +02:00
$(if $(PRIVATE_GROUP_STATIC_LIBRARIES),-Wl$(comma)--end-group) \
Add extra libgcc.a only for unbundled build. We can save some space for platform build with this. Previously an extra libgcc.a was put before libc.so so libraries built against new platform can run on old platforms. This is needed only for unbundled build. Bug: 8805022 Bug: 8247455 Change-Id: I3c3e0092b06ec3804659d5cae048d29e0d2bf7ad
2013-05-03 23:12:31 +02:00
$(if $(TARGET_BUILD_APPS),$(PRIVATE_TARGET_LIBGCC)) \
Link PRIVATE_TARGET_FDO_LIB before shared libraries For global declaration of FDO profile generation and usage, we need to link PRIVATE_TARGET_FDO_LIB (libgcov.a by default) prior to linking shared libraries. TARGET_FDO_LIB is set if feedback directed optimizations are in use, so we do not need to worry about consistent size increases from this change. Change-Id: I543903f58893816f037c9466f31b19dfe822fdf4
2013-08-07 09:00:39 +02:00
$(PRIVATE_TARGET_FDO_LIB) \
Link libgcc.a before shared libraries (especially libc.so). BUG: 8247455 Change-Id: Ia8816536ca95a7084e80c7f425f81658afea9609
2013-03-13 02:15:18 +01:00
$(call normalize-target-libraries,$(PRIVATE_ALL_SHARED_LIBRARIES)) \
-o $@ \
Support to build executables against the NDK Use "LOCAL_SDK_VERSION := <number>" to build against the NDK when you include $(BUILD_EXECUTABLE). Bug: 7170098 Change-Id: I4cebeae3355e79a4d2f2f5549ef0613ced77e3f0
2012-09-26 02:52:10 +02:00
$(PRIVATE_TARGET_GLOBAL_LDFLAGS) \
LOCAL_LDFLAGS should come after TARGET_GLOBAL_LDFLAGS A package can define a LOCAL_LDFLAGS. If a LOCAL_LDFLAGS exists, it should come after the global LDFLAGS, to allow the local flags to override the global flags. Change-Id: I6e44c17949c1f11c808d0ed3f327d63fb51a1468
2010-04-26 23:12:19 +02:00
$(PRIVATE_LDFLAGS) \
Support to build executables against the NDK Use "LOCAL_SDK_VERSION := <number>" to build against the NDK when you include $(BUILD_EXECUTABLE). Bug: 7170098 Change-Id: I4cebeae3355e79a4d2f2f5549ef0613ced77e3f0
2012-09-26 02:52:10 +02:00
$(PRIVATE_TARGET_LIBGCC) \
$(if $(filter true,$(PRIVATE_NO_CRT)),,$(PRIVATE_TARGET_CRTEND_O))
Initial Contribution
2008-10-21 16:00:00 +02:00
endef
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 Conflicts: core/combo/TARGET_linux-arm.mk
2013-12-27 20:09:36 +01:00
define $(combo_2nd_arch_prefix)transform-o-to-static-executable-inner
stop using a custom linker script for static executables. This is causing problems with making the linker relocatable. Change-Id: I53e37fba52eabd3145130712d6e9bff074aed493
2011-11-01 18:59:35 +01:00
$(hide) $(PRIVATE_CXX) -nostdlib -Bstatic \
Don't include system/core/include/arch/<arch>/Android.mk for apps-only build. Bug: 6994483 Change-Id: I76c4d96264cf94a79d59fdeb52bb37c07a9458dd
2012-08-17 01:45:01 +02:00
-Wl,--gc-sections \
Initial Contribution
2008-10-21 16:00:00 +02:00
-o $@ \
Support to build executables against the NDK Use "LOCAL_SDK_VERSION := <number>" to build against the NDK when you include $(BUILD_EXECUTABLE). Bug: 7170098 Change-Id: I4cebeae3355e79a4d2f2f5549ef0613ced77e3f0
2012-09-26 02:52:10 +02:00
$(PRIVATE_TARGET_GLOBAL_LD_DIRS) \
$(if $(filter true,$(PRIVATE_NO_CRT)),,$(PRIVATE_TARGET_CRTBEGIN_STATIC_O)) \
$(PRIVATE_TARGET_GLOBAL_LDFLAGS) \
LOCAL_LDFLAGS should come after TARGET_GLOBAL_LDFLAGS A package can define a LOCAL_LDFLAGS. If a LOCAL_LDFLAGS exists, it should come after the global LDFLAGS, to allow the local flags to override the global flags. Change-Id: I6e44c17949c1f11c808d0ed3f327d63fb51a1468
2010-04-26 23:12:19 +02:00
$(PRIVATE_LDFLAGS) \
Initial Contribution
2008-10-21 16:00:00 +02:00
$(PRIVATE_ALL_OBJECTS) \
Update build rule for executable with PRIVATE_ALL_WHOLE_STATIC_LIBRARIES Change-Id: I9ff53f51dcb57511a24765bdf6a61c000a7ce977 Signed-off-by: Kito Cheng <kito@0xlab.org>
2012-01-20 12:21:46 +01:00
-Wl,--whole-archive \
$(call normalize-target-libraries,$(PRIVATE_ALL_WHOLE_STATIC_LIBRARIES)) \
-Wl,--no-whole-archive \
Group needed libraries together to solve the cyclic dependence between libc, libc_nomalloc and libgcc. When building with upcoming arm-linux-androideabi toolchain, Symbol raise is needed by libgcc.a and defined by libc.a or libc_nomalloc.a.which. This patch groups libgc.a, libc_nomalloc.a and libgcc.a together, which is a minimal group to solve this problem. Change-Id: I27ed78c495dc53c1db7b302da8704f5e478ad893
2010-05-20 21:00:54 +02:00
$(call normalize-target-libraries,$(filter-out %libc_nomalloc.a,$(filter-out %libc.a,$(PRIVATE_ALL_STATIC_LIBRARIES)))) \
-Wl,--start-group \
$(call normalize-target-libraries,$(filter %libc.a,$(PRIVATE_ALL_STATIC_LIBRARIES))) \
$(call normalize-target-libraries,$(filter %libc_nomalloc.a,$(PRIVATE_ALL_STATIC_LIBRARIES))) \
Support to build executables against the NDK Use "LOCAL_SDK_VERSION := <number>" to build against the NDK when you include $(BUILD_EXECUTABLE). Bug: 7170098 Change-Id: I4cebeae3355e79a4d2f2f5549ef0613ced77e3f0
2012-09-26 02:52:10 +02:00
$(PRIVATE_TARGET_FDO_LIB) \
$(PRIVATE_TARGET_LIBGCC) \
Group needed libraries together to solve the cyclic dependence between libc, libc_nomalloc and libgcc. When building with upcoming arm-linux-androideabi toolchain, Symbol raise is needed by libgcc.a and defined by libc.a or libc_nomalloc.a.which. This patch groups libgc.a, libc_nomalloc.a and libgcc.a together, which is a minimal group to solve this problem. Change-Id: I27ed78c495dc53c1db7b302da8704f5e478ad893
2010-05-20 21:00:54 +02:00
-Wl,--end-group \
Support to build executables against the NDK Use "LOCAL_SDK_VERSION := <number>" to build against the NDK when you include $(BUILD_EXECUTABLE). Bug: 7170098 Change-Id: I4cebeae3355e79a4d2f2f5549ef0613ced77e3f0
2012-09-26 02:52:10 +02:00
$(if $(filter true,$(PRIVATE_NO_CRT)),,$(PRIVATE_TARGET_CRTEND_O))
Initial Contribution
2008-10-21 16:00:00 +02:00
endef
Reference in a new issue Copy permalink