In order to install 32-bit gdbserver on a 64-bit build,
prebuilts/misc/Android.mk needs to know the prebuilt directory name
for the 2nd arch.
Change-Id: Ibc943b758eb9404f7f5f9fbbd8720cc67f6a6f01
If the VM is libart and DEXPREOPT is enabled,
- For a Java library and the boot image, we build for both 1st arch and
2nd arch.
- For an app, we build for the multilib arch the module is targeted for.
The odex file will be in <arch_name>/<module_name>.odex inside the same
dir where the jar/apk file gets installed.
Nothing changed if it's built for libdvm.
Bug: 14694978
Change-Id: I45118a83758b41d52d6c9e38f93f0ba2775a6c74
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
If the product prefers 32-bit apps signal that preference to
PackageManager by reversing the abi list.
Also uses the absence of TARGET_SUPPORTS_32_BIT_APPS and
TARGET_SUPPORTS_64_BIT_APPS to remove those ABIs from the
ABI list.
Change-Id: I504cea21b6f800a7a9e7706b4a7123d3fb07c383
Introduce two new flags, TARGET_PREFER_32_BIT_APPS and
TARGET_PREFER_32_BIT_EXECUTABLES that individually control
compilation of apps and executables. If TARGET_PREFER_32_BIT is
set, the build system will automatically set both new flags.
Change-Id: Ibd2165e688675c2884d9e7ddf82d7dd6c28521f3
Introduce ro.product.cpu.abilist32 / abilist64, which are
comma separated lists of the 32 and 64 bit ABIs that the
device supports. These properties are used by the zygote and
system server to determine what ABI an app should be
started with.
This changes move abilist related make steps out of envsetup.mk
and into config.mk because they depend on variables set by
core/combo/***. Additionally, config.mk performs a few additional
cleanups of these variables (like stripping them) after the
inclusion of envsetup.mk so this seems like a better place to
put them.
bug: 13647418
Change-Id: I3db39bdd761220c5b4966f651892fb592396f9a1
All introduce a flag LEGACY_USE_JAVA6 to force java6 builds.
This is an unsupported configuration, and provided temporarily
to iron out regressions and compare build output (if required.).
- Increment the version check sequence number.
- Move a more specific check (OpenJDK vs non OpenJDK) after
the more general version check.
- Update the link in the version check error message to the
"initializing" page instead of the "download" page. The latter
talks about repo, mainly.
bug: 8992787
Change-Id: I313e17b1911768d4f3bc318c4162c53dec6eaf0d
Conflicts:
core/main.mk
1) Disable dexpreopt if DALVIK_VM_LIB isn't set up by the product.
2) DEX2OAT_TARGET_INSTRUCTION_SET_FEATURES is moved to config.mk,
for it's only decided by target arch.
3) Move Java module input from embedded.mk to base.mk.
Change-Id: Ife70b0cd8cee2e5c92f356c808affa56f494b49a
Analyzer needed by WITH_STATIC_ANALYZER and WITH_SYNTAX_CHECK is
moved from prebuilts/clang/{linux-x86,darwin-x86}/host/3.3 to
prebuilts/misc/{linux-x86,darwin-x86}/analyzer
See https://android-review.googlesource.com/#/c/83852/
BUG=13243591
Usage:
"WITH_SYNTAX_CHECK=1 make ..." instructs build system to invoke "clang -fsyntax-only"
to utilize clang's better diagnostics before calling LOCAL_CC/LOCAL_CXX for code generation.
The compilation time is slightly longer, and the generated object file should be the same as
w/o WITH_SYNTAX_CHECK
"WITH_STATIC_ANALYZER=1 m/mm/mmm/mma/mmma ..." instructs build system to run static
analyzer via "clang --analyze" on a successful build. If analyzer finds any issue, instruction
to open report is displayed. See http://clang-analyzer.llvm.org/scan-build.html for details.
WITH_STATIC_ANALYZER trumps WITH_SYNTAX_CHECK if both exist. Project use lots of GCC extensions
(eg. nested function) not supported by clang may opt out by adding LOCAL_NO_STATIC_ANALYZER:=true
Change-Id: Ib3dda3ffb0fd3aaf2eadec867a966d1dd2868fb1
1. Following the setup of gcc in build/core/combo/,
we added the [HOST|TARGET]_<arch>.mk clang config files,
and load only the configs needed by the current product.
2. Added support for the 2nd arch.
Change-Id: I2a383418a9688a050b39492f8e489d40eeeb5f2d
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
/system/lib always contains 32-bit libraries, and /system/lib64 (if
present) always contains 64-bit libraries.
Move things around a little bit, so TARGET_ARCH can be used to define
the build paths.
Bug: 11654773
Change-Id: I2edd91e162c7a20d7719d7bae15e5fa6c2a5b498
We currently have two types of host libraries, those
meant for the host VM (Sun, OpenJDK etc.) and those meant
for a host dalvik build. The former need to be compiled
against the host standard libraries and the latter need
to be compiled against libcore. This change introduces
two new build rules to complement the existing the existing
host rules.
BUILD_HOST_DALVIK_JAVA_LIBRARY : Build a java library for
a host build of dalvik. Bootclasspath will be set to a host
build of libcore.
BUILD_HOST_DALVIK_STATIC_JAVA_LIBRARY : Build a static java
library for a host build of dalvik. Bootclasspath will be set
to a host build of libcore.
This change also removes support for the LOCAL_BUILD_HOST_DEX
flag, which is now unnecessary.
bug: 8992787
(cherry picked from commit 0dd273a3f6)
Change-Id: I3569fff8eaa4d26d55fcc317bd98471f55d74c14
The new option WITH_STATIC_ANALYZER=1 instructs build system to
run static analyzer via "clang --analyze" on a successful build.
If analyzer finds any issue, instruction to open report is displayed.
See http://clang-analyzer.llvm.org/scan-build.html for details.
WITH_STATIC_ANALYZER trumps WITH_SYNTAX_CHECK if both exist.
Project use lots of GCC extensions (eg. nested function) not supported
by clang may opt out by adding LOCAL_NO_STATIC_ANALYZER:=true
Change-Id: I9970560560bd52ce5f0fd7129c3488629627c735
The new option WITH_SYNTAX_CHECK=1 instructs build system to invoke
"clang -fsyntax-only" to utilize clang's better diagnostics before calling
LOCAL_CC/LOCAL_CXX for code generation. The compilation time is slightly
longer, and the generated object file should be the same as w/o WITH_SYNTAX_CHECK
Project use lots of GCC extensions (eg. nested function) not supported
by clang may opt out by adding LOCAL_NO_SYNTAX_CHECK:=true
Change-Id: I5689586788ef049bd967364f71f31f1e359bd121
Support using custom mkbootimg to allow boards to specify custom
boot image formats. Also export this as the environment variable
MKBOOTIMG to the *_from_target_files releasetools scripts.
Change-Id: I2084273b1175de097fb7da5c4f2264ea8014d74f
Signed-off-by: Bjorn Andersson <bjorn.andersson@sonymobile.com>
Don't bother going through the source tree in more circumstances:
all cleaning goals, helping goals, no-deps goals.
Bug: 10244578
Change-Id: Id53a249085c62838e4193962a85e0ac34f46954f
AndroidProducts.mk allows for a maxdepth of 4 in device and vendor while
vendorsetup.sh and BoardConfig.mk only allow for smaller depth.
Make search depth consistent for these files.
Change-Id: I406770c1423d4f27fe097956a7c705a0da937e35
Signed-off-by: Beare, Bruce J <bruce.j.beare@intel.com>
Signed-off-by: Laurent Fert <laurent.fert@intel.com>
Signed-off-by: Guilhem Imberton <guilhem.imberton@intel.com>
Author: Laurent Fert <laurent.fert@intel.com>
Brian Carlstrom