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 uses the fact that unsetting LOCAL_MULTILIB equals "either".
It's useful to build for both 32-bit and 64-bit in the same prebuilt
module definition.
Bug: 13751317
Change-Id: I4f1625a83e13f22f807039afebae73f69ed35918
Currently, skin directory remains across different emulator targets, and
need manual removal. Also, clear hardware-qemu.ini and config.ini.
(See https://android-review.googlesource.com/94692 for config.ini)
Change-Id: Iaa5849ad043ed3f317325ba1d6df287953636f7a
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
32 bit targets will leave TARGET_PREFER_{32,64}_BIT_APPS unset
so adjust accordingly. Also clean up an explanatory comment.
Change-Id: I1f6faa640e4e862631fff49f7c565766ef2c567f
GCC know a few pre-defined paths (relative to its location) to
search for headers, libraries, program, etc. By default GCC prefixes
its own path(argv[0]) and calls realpath() which result in absolute
path with all symlink, . and .. removed.
It's usually good to have canonicalised paths, but absolute paths
in *.d file can cause unnecessary relinking when stale entries
in ccache cache hit
Add -no-canonical-prefixes (gcc>=4.6) and
-fno-canonical-system-headers (gcc>4.6) to disable realpath() on
prefixed paths
Change-Id: I58d739e61fb013015fb05a9c98b2132b307f915a
Now that emulator prebuilts are available under prebuilts/android-emulator/,
disable building the emulator from source in all platform builds, except
if one defines BUILD_EMULATOR to 'true' in its environment.
NOTE: This patch should be applied after this one to avoid issues
with the GPU emulation libraries:
https://android-review.googlesource.com/93980
Change-Id: I53b2ada9ca0c2e159dccee7cdca7f55f6b0d1d42
For a 64bit target, we can have support for both 32bit and 64bit version
binary(like app_process, dalvikvm), and there are some commands like am/pm
will call these commands to implement it's function.
In some targets it will prefer to use the 32bit version, and in other targets
it will prefer to use the 64bit version. So this change is to add the common
work for creating the symlink to the prefer version binary,and avoid the
change on the caller commands side like am/pm.
In this change, it uses TARGET_PREFER_32_BIT_APPS to decide linking to
32bit version or 64bit version.
Change-Id: I96f041c0e0ededd953feead30ec63ad63e945a6f
Signed-off-by: Yongqin Liu <yongqin.liu@linaro.org>
Some printf/scanf functions in Windows aren't C99 compatible.
Define __USE_MINGW_ANSI_STDIO for mingw compiler to use it's own set of
replacement libraries which are more C99-like.
Change-Id: I51dfa582971ec0487409067e8bb7fe3a44577b93
* Currently the flag conflicts with one seen in hardware/qcom
rename to avoid issues.
Change-Id: I876fcd6a254f349dc5260509bcddb0367a7d49d8
Signed-off-by: Nick Reuter <nreuter85@gmail.com>
But not install them.
This prevents "make tests" polluting system.img or userdata.img.
We have new mechanism to build and package up modules into zip file in
build/core/tasks/tools.
Change package-modules.mk to install DATA/ instead of data/ in the
zip file; Better handle of module name conflicting.
Bug: 13585955
Change-Id: I7586a8c7995b984c9ead0ba2fa84dd5d2dd20bd1
With this change, you can package up modules while avoiding installing
them to the system.img or userdata.img.
- build/core/tasks/tools/package-modules.mk
You can use this template to package up modules into a zip file and
preserve the installed file paths.
- LOCAL_PICKUP_FILES, you can use this variable to package up extra
files/directories.
Bug: 13585955
Change-Id: I103042b24ccf17cf5dc90c016d97ed1dd293e50b
Use LOCAL_LDLIBS to link against prebuilt libraries (such as NDK
libraries).
Previously LOCAL_LDLIBS only applies to host modules and the behaviour
confuses users.
Change-Id: I515546d7b59ef54e8ef09050eb58ec63534c9291
* changes:
build: add core_64_bit.mk
build: reverse abi list when TARGET_PREFER_32_BIT_APPS is set
build: split TARGET_PREFER_32_BIT for apps and executables
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
This is used for Baytrail targets.
Change-Id: I5a2fa6dbb8217a326ee09f5ea434885718ab3f0c
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
Signed-off-by: Pavel Chupin <pavel.v.chupin@intel.com>
Signed-off-by: Fengwei Yin <fengwei.yin@intel.com>
