GCC: 4.9 (which supports -fstack-protector)
Binutils: 2.24 (which supports gc-sections)
GDB: 7.7
NDK libraries are still picked up from prebuilts/ndk/*/4.8/*
GCC has been patched to disable codegen for calling
__cxa_throw_bad_array_new_length.
Source code has been sync'ed against the 2014-05-14 snapshot which
contains many important fixes (devirtualization, codegen, ...).
Change-Id: I43229360ad0132193d5208cb0d1acba55084853c
Basically, allow access of qemu_device where gpu_device is allowed, for the
case when the emulator runs with OpenGL/ES emulation. Most noticably,
surfaceflinger crashes without qemu_device access.
Bug: 15052949
Change-Id: Ib891365a6d503309bced64e2512c4d8f29d9a07e
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
When signing an APK, make the SignApk tool align the stored entries to
(by default) 4-byte boundaries. This obviates the need to run the
separate zipalign tool, which currently does this job.
The alignment byte count can be specified with the -a option. OTA
package signing (with -w) never does alignment.
The order of files in the output APK is changed so that all stored
files come first in the output, followed by all non-stored files.
This is not expected to have any impact in practice.
Change-Id: Iaeef89b2a7283e25fadb99c0a0f0641f682d76b8
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