The instruction URL has been amended and a few additional
details have been added.
(cherry picked from 8c06afdea3)
Change-Id: Icaffc3b13ed881ac7e29f2021ed31eb1f877a5ab
* Fix: my_target_global_ldflags is defined in binary.mk
so they effectivelly override previous definition
Change-Id: I9c7d9bde82c3a6d25a94ae109fa71ecaa33640b0
These lines were removed in aosp in commit e2d27887b
but a bad merge conflict resolution left them in master.
Subsequent changes on master started using these variables
so they're being brought back.
Change-Id: Ic8f3c295130c47eb0d66057880f9d4f70c89af94
Change-Id: I91d6ff72629523050b4f26c2d731cac90ef49348
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
Reviewed-by: Jovanovic, Radivoje <radivoje.jovanovic@intel.com>
Reviewed-by: Boie, Andrew P <andrew.p.boie@intel.com>
Reviewed-by: Kumar-mayernik, Nisha <nisha.kumar-mayernik@intel.com>
Reviewed-by: Gumbel, Matthew K <matthew.k.gumbel@intel.com>
Tested-by: Gumbel, Matthew K <matthew.k.gumbel@intel.com>
_JAVA_OPTIONS is an environment variable that
can be used to affect the behavior of java and javac.
It is currently required to get Android to build on
some configurations, where the default Java heap size
is too small. Unfortunately, if _JAVA_OPTIONS is set,
both java and javac will output its value to the console
as the first line on every invocation, including trivial
ones like java -version. This will confuse main.mk’s
version detection, which only looks at the first line of
output. Tweak the version detection to run grep before
head, so that the _JAVA_OPTIONS line is filtered by the grep.
Change-Id: I69aee52b56d27711b7d3087ec6b3ebab07ffc3af
Add a (read only) system property that is a comma
separated list of ABIs supported by the device in order
of preference. For example, typical arm-v8 device might
define:
ro.cpu.abilist = arm64-v8a,armeabi-v7a,armeabi
For most purposes, a single flattened list like the above is
probably more useful than the parallel system of variables
TARGET_CPU_ABI{2} / TARGET_2ND_ARCH_CPU_ABI{2} that we use
in the build system.
Change-Id: If9102669ad9f5f8fd89a8bcc5bf88cca1acadc3c
LOCAL_MULTILIB replaces LOCAL_32_BIT_ONLY and
LOCAL_NO_2ND_ARCH, although both are still supported.
Set LOCAL_MULTILIB := 32 to always build a module 32-bit.
This is the same as specifying LOCAL_32_BIT_ONLY.
Set LOCAL_MULTILIB := first to always build a module for
the first architecture (64-bit on a 64-bit target, 32-bit on a
32-bit target). This is the same as specifying LOCAL_NO_2ND_ARCH.
Set LOCAL_MULTILIB := both to build for both architectures
on a mulitlib (64-bit) target.
If LOCAL_MULTILIB is not set libraries will default to "both",
and executables, packages, and prebuilts will default to building
for the first architecture if supported by the module, otherwise
the second.
Executables that set LOCAL_MULTILIB := both must set either
LOCAL_MODULE_STEM_32 and LOCAL_MODULE_STEM_64 or
LOCAL_MODULE_PATH_32 and LOCAL_MODULE_PATH_64 to specify how to
differentiate the install locations of the two versions.
Change-Id: I22ab6aa342b231c307b1d8a86cea4fd91eea39f5
* commit '36a67a9040f35fc47c0ea5cafa61910a7e2fcc66':
add support for LOCAL_MODULE_STEM_32 and LOCAL_MODULE_STEM_64
add support for LOCAL_MODULE_PATH_32 and LOCAL_MODULE_PATH_64
Some executables will need to be built for both 32-bit and 64-bit.
For linker/linker64, debuggerd/debuggerd64, and a few more, they
will be installed in the same path (/system/bin), but with different
filenames. Allow the module to specify LOCAL_MODULE_STEM_32 and
LOCAL_MODULE_STEM_64 to name the two versions.
Change-Id: I573e8678c7332245a064f31246be0a05f0a9e25f
Some executables will need to be built for both 32-bit and 64-bit.
For tests, it will be convienient to keep the name of the executable
the same, but install them in a different location. Add
LOCAL_MODULE_PATH_32 and LOCAL_MODULE_PATH_64 to allow a module
to specify different paths for 32-bit and 64-bit executables.
Change-Id: I3be830e899c6d485fe55c25c66b20b3fe64c795e
Narayan Kamath