When the VM is libdvm, we don't put the odex files in an arch specific
subdirectory. The previous pattern rules don't work because of the extra
"/". With this change, % evaluates to empty string when it's built for
libdvm; % evaluates to "<arch_name>/" when it's built for libart.
Also removed use of $(create-empty-package), which may causes file name
(dummy) conflict with the rule of package.apk.
Bug: 15311527
Change-Id: I9f9089bc1896b78c1f47834afdb28a3a51d34480
x86 just bit me. I did manage to build mips today, but I assume it
can't be long before we hit the limit there too if every other target
has hit it already.
Change-Id: I28dfe3b4f9565cb79e0bf6b0ffc55a9d6e64a9b0
Also siezes the opportunity to remove the hardcoded
TARGET_PREFER_32_BIT_APPS directing in core_64_bit.mk.
This avoids the need for further hacks but needs supporting
changes to a few apps to force them to 32 bit.
Change-Id: I36ba9e5f5b08dd87d6a4afc27961a436306eed99
This isn't required any longer, besides individual products
should be allowed to set this value themselves.
(cherry picked from commit 7b9347a7f9)
Change-Id: If459eab32c6e7831596224ad3503baefbf028133
_extract-and-include-single-(host|target)-whole-static-lib was written such that
only the first file of a given name would be extracted and included into the new
library. This patch iterates over each identically named archive member,
extracts them individually, and adds them to the new archive.
Bug: 15110069
Change-Id: Ia08c7be6f40bfc8403908a8808898ada479099b1
* commit 'e45c8607b3e2cf7a428a91898aea2752a54389a1':
set a prebuilt directory name for the 2nd arch
add vendor directories to gdb shared library search path
add 2nd arch gcc to the path
fix paths when 2nd arch gcc is a different version
* changes:
set a prebuilt directory name for the 2nd arch
add vendor directories to gdb shared library search path
add 2nd arch gcc to the path
fix paths when 2nd arch gcc is a different version
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
arm64 is using gcc 4.9, arm is using gcc 4.8. Fix setpaths() to
get a separate version for the 2nd arch.
Change-Id: I7bde01308fc7718360e7d0fbd46b3ae8c5f55fa7
Previously the odex file is byproduct generated by the package.apk rule.
Though we have the odex file depend on the package.apk it doesn't have
its own build recipe. In case package.apk isn't updated but we still
need to update the odex file (such as changed LOCAL_MULTILIB), the odex
file will never be rebuilt.
This change split out the rules to build the odex file and make sure the
build recipe get executed if the odex file needs rebuild.
Change-Id: I60c2f32b536b3d59045301ee863aae1451734aad
We already support pure 32-bit and 64-bit-by-default multilib build.
With HOST_PREFER_32_BIT we can build 32-bit-by-default multilib build.
This will be lest disruptive during the period we transition to
64-bit-by-default.
Bug: 13751317
Change-Id: I0d56ce4abbe4afeaacfd70d709f6a349791c0722
Use LOCAL_PREBUILT_JNI_LIBS to install prebuilt JNI libraries extracted
from the prebuilt apk, or prebuilts as source, to the app specific lib path.
LOCAL_PREBUILT_JNI_LIBS accepts 2 kinds of files:
- Files like @path/to/libfoo.so (path inside the apk) are JNI libs
extracted from the prebuilt apk. In this case, all embedded JNI libs
inside the prebuilt apk are stripped.
- Files like path/to/libfoo.so (path relative to LOCAL_PATH) are
prebuilts in the source tree.
Those prebuilt JNI libs are not defined as modules in the build system,
so this works around possible module name conflict.
Bug: 13170859
Change-Id: I91bb844cc11b3621a85733bc7e8910f168957ef0
