This change basically ported our target multilib to the host side.
It supports 2 host build modes: x86 and x86_64 multilib build.
For now you need to set "BUILD_HOST_64bit=true" to switch to x86_64
multilib build. Later we'll default to x86_64 build and have a flag
to force 32-bit only build, which may be needed by SDK build.
In host module definition, like in target ones, you can use the
following
LOCAL variables to set up multilib configuration:
LOCAL_MULTILIB: can be "both", "first", "32" or "64".
It also supports the same set of arch or 32-vs-64 specific LOCAL
variables.
By default, it builds only for the first arch.
To keep path compatibility, in x86_64 build files are still output to
out/host/linux-x86; Both 32-bit and 64-bit executables are in
out/host/linux-86/bin;
In x86_64 build 32-bit shared libraries are installed to
out/host/linux-x86/lib32
and 64-bit shared libraries are installed to out/host/linux-x86/lib;
32-bit object files are output to out/host/linux-x86/obj32 and 64-bit
object files
are output to out/host/linux-x86/obj.
Bug: 13751317
Change-Id: I6044f83b7db369a33e05209e8c588eb6dc83409f
"GYP" class targets are used by external/chromium_org for gyp's "none"
type. The processing in these targets needs a separate intermediate
directory for the primary/secondary architecture, so add it to the list
in intermediates-dir-for along with libraries/executables.
Change-Id: Id05899c83b45ed0647dfbfa6b0b2e7f61b04348b
When LOCAL_STRIP_MODULE := keep_symbols is set, then the normal strip rules
will be modified so that only the .debug_* sections are removed. The original
symbol table is left alone.
This allows the compilation of certain libraries so that libbacktrace library
can provide meaningful names to functions.
Bug: 12958251
Change-Id: I82bdc304a463012e29086325ccb51163464cb4a9
Depending on the file extension of the generated C++ file,
bison will generate a #include of a .h or .hpp. So both files
must be kept in the generated directory.
Change-Id: Id0aac7f407bdc69c7f5012c0d021761b0fceb427
For host executables and shared libraries, the global LDFLAGS were being
inserted into the linker command line after the module-specific ones,
making it impossible to override the default settings. Change the order
to match target linker invocations.
Change-Id: Icd5f6f83df9f27a5be97ddb197ee245c1ab8c2be
2ND_TARGET_DEPENDENCIES_ON_SHARED_LIBRARIES was not set,
which was causing the later += to act like = instead of
:=, and the dependencies would disappear as soon as
LOCAL_MODULE was cleared.
Change-Id: Idea291524fc06377deafec62f37d20eaa7f93bca
Allow modules to generate source into $OUT/gen, which will then
be copied into $OUT/obj and $OUT/obj_$(TARGET_2ND_ARCH) as
necessary. This allows a single build rule invocation that includes
generated source to build for the first and second architectures.
Modules will need to change calls to local-intermediates-dir into
local-generated-sources-dir.
Change-Id: I62504bad9454b3d9fde7b84ab9f0a487a2ecf0bf
By default, an executable is built for TARGET_ARCH.
To build it for TARGET_2ND_ARCH in a 64bit product, use:
LOCAL_32BIT_ONLY := true
To skip a module for TARGET_2ND_ARCH, use:
LOCAL_NO_2ND_ARCH := true
Bug: 11654773
Change-Id: Ieb293d25b21024bfe1b554044df338e064ac7b46
The rules for the 2nd arch are set up in the second inclusion
of shared_library_internal.mk.
Intermediate fils of libfoo of the 2nd arch will be built into
$(PRODUCT_OUT)/obj_$(TARGET_2ND_ARCH)/SHARED_LIBRARIES/libfoo_intermediates/
and the built libfoo.so will be in
$(PRODUCT_OUT)/obj_$(TARGET_2ND_ARCH)/lib.
Bug: 11654773
Change-Id: I58bbe5a05a65f63bce6279131552f3792000716e
The rules for the 2nd arch are set up in the second inclusion
of static_library_internal.mk.
libfoo of the 2nd arch will be built into
$(PRODUCT_OUT)/obj_$(TARGET_2ND_ARCH)/libfoo_intermediates/libfoo.a.
Bug: 11654773
Change-Id: I1d92733968fc442e9225b4df5bd1b551a81d89f7
Compile all host programs for Android with -fPIE and -pie. This
enables PIE (Position Independent Executables), which helps
protect these applications from exploitation due to memory
management bugs.
Note: PIE *static* executables are not supported at this time. darwin
and windows are also not supported.
Change-Id: I67c1be297711ea23064c349f97ebd02eef3eff09
find-files-in-subdirs uses utility find to find given files in the given
subdirs. This function uses $(1), instead of LOCAL_PATH as the base.
Change-Id: Ib76631c97acd257d651a580cbad767606874f5d0
(cherry picked from commit 85898bca99)
find-files-in-subdirs uses utility find to find given files in the given
subdirs. This function uses $(1), instead of LOCAL_PATH as the base.
Change-Id: Ib76631c97acd257d651a580cbad767606874f5d0
With this change, use:
* LOCAL_PROGUARD_ENABLED := obfuscation # to enable obfuscation
* LOCAL_PROGUARD_ENABLED := optimization # to enable optimization
* LOCAL_PROGUARD_ENABLED := obfuscation optimization # to enable both
Now the meaning of the LOCAL_PROGUARD_ENABLED options:
* full:
Use the build system's default configurations:
with shrink but no obfuscation or optimization,
global proguard flags in build/core/proguard.flags
are applied.
* custom:
The same as "full" except no aapt-generated resource-related
proguard flags.
* nosystem:
Don't use any build system's default configurations; but
aapt-generated proguard flags are still applied. You are
responsible for any other flags.
* disabled:
Disable proguard.
* obfuscation:
The same as "full" but with obfuscation enabled.
* optimization:
The same as "full" but with optimization enabled.
* no value (the default):
The build system chooses the proper value: "full" if it's an
app; "disabled" if it's a library.
You can use more than 1 of them in a meaningful combination,
for example:
LOCAL_PROGUARD_ENABLED := obfuscation optimization
Bug: 10307372
Change-Id: Id248caca3048e99547f16559fae74f4afe85c354
