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
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
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
Add some more gcc specific flags that are used somewhere in the tree
(e.g. external/chromium_org) to CLANG_CONFIG_UNKNOWN_CFLAGS
Change-Id: Icc572fdb6ea4ba818c4d18e430296589eb61bf55
Signed-off-by: Bernhard Rosenkraenzer <Bernhard.Rosenkranzer@linaro.org>
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
* commit '2ff8919de339209412d9da2a524f566dfcf5847f':
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
* 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>
external/chromium-libpac has been updated to depend on the copy of V8 in
external/chromium_org, and its makefiles updated to be multilib-safe.
external/v8 is thus unused and has been removed from the tree.
Bug: 12452053
Change-Id: I757fa187f7f67cd9a89d4b228d4ce3ed6d2858b1
prebuilts/ndk/current/platforms/android-19/arch-x86_64/usr/lib
is renamed to usr/lib64 to be more consistent with rest of
lib paths in x86_64 toolchain, which is multilib
See https://android-review.googlesource.com/#/c/92441/
Change-Id: I4e59245505d0fa87ae3608e81e715ccfcecc5ec8
external/chromium_org has been updated to handle 64-bit architectures
correctly in its makefiles; remove it from the blacklist so we can start
experimenting with building a 64/32 multilib version.
Change-Id: Ieb0e4f3cfea1578e01954c4656df90cd8d36b8cc
Previously we have to use LOCAL_REQUIRED_MODULES to install jni
libraries for an apk in bundled build.
With this change, we'll use LOCAL_JNI_SHARED_LIBRARIES alone to
install jni shared libraries.
The new rules are:
- If we are doing unbundled build, or the apk isn't going to be
installed to system partitions, we'll embed the jni libs in the
built apk.
- Otherwise, the jni libraries will be installed to the system
lib path, and symlinks created in the app specific lib path.
Change-Id: Id6bd5301eb632bda3593664acee580f0d8b1d5d4
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.
Change-Id: Ie0bf38357c0cf3d265d8b5dd3c2b8a8fd83b1de1
The "-maarch64linux" switch is needed before aarch64-*4.8 is rebuilt with
backport of upstream patch, see https://android-review.googlesource.com/#/c/91099/
The existing ld.bfd is fine because it's configured to support
aarch64linux only. ld.mcld (see https://android-review.googlesource.com/#/c/91047)
needs explicit emulation switch because it supports multiple targets
Change-Id: Idc1a491c5722ea9e26db917b667b1000bccc1f60
Delete LOCAL_NO_2ND_ARCH, it is no longer used. Equivalent
functionality is available with LOCAL_MULTILIB := first.
Change-Id: I36838a8a7e10b0a59ca0022c4c8a3a190e782c71
LGPL projects need their source code distributed under very
similar conditions to GPL and MPL, the only difference is the
conditions under which they may be linked. It makes sense to
include them in the GPL archive tarballs.
Change-Id: I2c2df03906bfeee55566102aa688e4cdc283700b
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
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.
Change-Id: Ie647fc4c6b227d6bee792f04d5c2f02eb0099559
Everything under packages/ will build for 64-bit now, and
package.mk has been updated to not produce 64-bit libraries
on devices that don't support them (all of them right now).
Change-Id: I2c10e41f727cfc8fe237819308a6dfa34c4fff3f
Use TARGET_SUPPORTS_32_BIT_APPS and TARGET_SUPPORTS_64_BIT_APPS to
determine which native libraries to build for an app. If
both are set, it will use 64-bit unless TARGET_PREFER_32_BIT is set.
If only one is set, it will only build apps that work on that
architecture. If neither is set it will fall back to only building
32-bit apps.
On existing 32-bit devices neither variable will be set, and the
build system will continue to build 32-bit apps.
Once a device has support for a 64-bit runtime, the same logic
that selects the dual runtimes should set TARGET_SUPPORTS_32_BIT_APPS
and TARGET_SUPPORTS_64_BIT_APPS, and packages will be built for
the preferred arch, or fall back to the non-preferrred arch if
necessary.
For testing, a device may set TARGET_SUPPORTS_64_BIT_APPS without
TARGET_SUPPORTS_32_BIT_APPS to produce only 64-bit apps.
Change-Id: I5b5e23f15602c3cf9bd96791971208a85492c7a3
I don't expect it to be useful for modules, but package.mk will
use it to only install 64-bit native apps on devices that
only have a 64-bit zygote.
Change-Id: If3f5a81c3a60bd13fa6ded08e2a7579a29877324
TARGET_PREFER_32_BIT can't assume that the 32-bit rule is allowed,
it needs to try the 32-bit rule first, then fall back to the 64-bit
rule in case the module specifies LOCAL_MODULE_TARGET_ARCH or
LOCAL_MODULE_UNSUPPORTED_TARGET_ARCH to disallow the 32-bit build.
Also port TARGET_PREFER_32_BIT to package.mk.
Change-Id: I07520b75c4ee11a1e95a82b3afa2a33d4907eb04
We no longer provide this function in bionic. All callers
should be moved over to pthread_condattr_setclock().
Change-Id: Iccd3384b40de423f7d5f9521b6d8073bf8bdea42
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
It seems to be a javac/javadoc bug.
See https://code.google.com/p/doclava/issues/detail?id=38
sun.util.resources.OpenListResourceBundle is a class defined in the host rt.jar,
but sometimes on some platform javadoc/javac can't find it.
-XDignore.symbol.file tells javadoc/javac to skip the stubs file ct.sym
and link against rt.jar directly.
Change-Id: I3930f7399fc14b2d6b43c29f737fa90f37515aff
- If it's host module, don't set bootclasspath;
- If it's arget module,
- It can build against the API stubs;
- It can build against a historical SDK version;
- It can build against core.jar
Change-Id: Id1ec3ba624bc38068b206ad7173f4facf590e021
We want javadoc generated from the standard libraries
we supply and not the host standard libraries.
This also has the side effect of fixing javadoc generation
for java7 APIs that android introduced, while compiling
with java6.
bug: 8992787
Change-Id: Idebc7e12c7743a43b425ef4971f4482719fd480d
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
Unfortunately the previous approach of grepping out java version before
"head -n 1" clash with the effort of running "java -version" only once.
Change-Id: Ic78719c3bf1a54a45342d74bbbfa8e83bbc1bce1
The instruction URL has been amended and a few additional
details have been added.
(cherry picked from 8c06afdea3)
Change-Id: Icaffc3b13ed881ac7e29f2021ed31eb1f877a5ab
"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
* Fix: my_target_global_ldflags is defined in binary.mk
so they effectivelly override previous definition
Change-Id: I9c7d9bde82c3a6d25a94ae109fa71ecaa33640b0
These lines were removed in aosp in commit e2d27887b
but a bad merge conflict resolution left them in master.
Subsequent changes on master started using these variables
so they're being brought back.
Change-Id: Ic8f3c295130c47eb0d66057880f9d4f70c89af94
Change-Id: I91d6ff72629523050b4f26c2d731cac90ef49348
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
Reviewed-by: Jovanovic, Radivoje <radivoje.jovanovic@intel.com>
Reviewed-by: Boie, Andrew P <andrew.p.boie@intel.com>
Reviewed-by: Kumar-mayernik, Nisha <nisha.kumar-mayernik@intel.com>
Reviewed-by: Gumbel, Matthew K <matthew.k.gumbel@intel.com>
Tested-by: Gumbel, Matthew K <matthew.k.gumbel@intel.com>
_JAVA_OPTIONS is an environment variable that
can be used to affect the behavior of java and javac.
It is currently required to get Android to build on
some configurations, where the default Java heap size
is too small. Unfortunately, if _JAVA_OPTIONS is set,
both java and javac will output its value to the console
as the first line on every invocation, including trivial
ones like java -version. This will confuse main.mk’s
version detection, which only looks at the first line of
output. Tweak the version detection to run grep before
head, so that the _JAVA_OPTIONS line is filtered by the grep.
Change-Id: I69aee52b56d27711b7d3087ec6b3ebab07ffc3af
Add a (read only) system property that is a comma
separated list of ABIs supported by the device in order
of preference. For example, typical arm-v8 device might
define:
ro.cpu.abilist = arm64-v8a,armeabi-v7a,armeabi
For most purposes, a single flattened list like the above is
probably more useful than the parallel system of variables
TARGET_CPU_ABI{2} / TARGET_2ND_ARCH_CPU_ABI{2} that we use
in the build system.
Change-Id: If9102669ad9f5f8fd89a8bcc5bf88cca1acadc3c
LOCAL_MULTILIB replaces LOCAL_32_BIT_ONLY and
LOCAL_NO_2ND_ARCH, although both are still supported.
Set LOCAL_MULTILIB := 32 to always build a module 32-bit.
This is the same as specifying LOCAL_32_BIT_ONLY.
Set LOCAL_MULTILIB := first to always build a module for
the first architecture (64-bit on a 64-bit target, 32-bit on a
32-bit target). This is the same as specifying LOCAL_NO_2ND_ARCH.
Set LOCAL_MULTILIB := both to build for both architectures
on a mulitlib (64-bit) target.
If LOCAL_MULTILIB is not set libraries will default to "both",
and executables, packages, and prebuilts will default to building
for the first architecture if supported by the module, otherwise
the second.
Executables that set LOCAL_MULTILIB := both must set either
LOCAL_MODULE_STEM_32 and LOCAL_MODULE_STEM_64 or
LOCAL_MODULE_PATH_32 and LOCAL_MODULE_PATH_64 to specify how to
differentiate the install locations of the two versions.
Change-Id: I22ab6aa342b231c307b1d8a86cea4fd91eea39f5
Some executables will need to be built for both 32-bit and 64-bit.
For linker/linker64, debuggerd/debuggerd64, and a few more, they
will be installed in the same path (/system/bin), but with different
filenames. Allow the module to specify LOCAL_MODULE_STEM_32 and
LOCAL_MODULE_STEM_64 to name the two versions.
Change-Id: I573e8678c7332245a064f31246be0a05f0a9e25f
Some executables will need to be built for both 32-bit and 64-bit.
For tests, it will be convienient to keep the name of the executable
the same, but install them in a different location. Add
LOCAL_MODULE_PATH_32 and LOCAL_MODULE_PATH_64 to allow a module
to specify different paths for 32-bit and 64-bit executables.
Change-Id: I3be830e899c6d485fe55c25c66b20b3fe64c795e
This lays the groundwork for making builds hermetic on Darwin as well.
That will be fixed in a future patch.
bug 13435344
Change-Id: Iae82d0b9efad0598d682ff5fd4daa737aa607866
Previously we have only one set of include/lib paths for
LOCAL_NDK_STL_VARIANT:=gnustl_static regardless of GCC
version, which is wrong because each GCC version
come with its own libstdc++.
Change-Id: I2a01c2120b6948aedce00e2f8d08dfc6932126dd
Previously the installed shared library dependency doesn't include
modules introduced by LOCAL_SHARED_LIBRARIES_<arch>.
This change fix the problem.
It also cleans up use of the shared library variable.
Bug: 13528787
Change-Id: Id8d807cc57f0ec4a71f18b64545d91191efad8fb
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
Required for getting ART with valgrind on device working since
valgrind maps things in the 0x60000000 address range.
Bug: 13323732
Change-Id: I05efdbf3fe5acd1418e1d4ced5844154fb4c5d37
- external/chromium now compiles
- stagefright codecs now compile.
- frameworks/base now compiles.
Change-Id: I1226b79cd3e0b5e2fd786bb506e022b47fe5e264
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
Now we have enabled arm64 clang.
This change remvoed arm64 clang build warning and cleaned the
arm64 unknow c flags.
Change-Id: Ia583a78c6d364e603ff09df423aa34a6e03d0b9b
This isn't the same as chromium_org (which is used by the
webview). This is a 3 year old snapshot of the net stack which
compiles under 64 bit. It's currently used on aosp master by
libstagefright_chromium_http.
This project can be removed if the changes that remove the
chromium dependency are cherry-picked to aosp/master.
Change-Id: I5d0f9ed03ea9842b47d980d77ea32bc7a3f6998f
- external/skia now builds on arm64, frameworks/base/libs/hwui
depends on it.
- external/bluetooth/bluedroid builds on 64 bit, though there
isn't any obvious way to test it without real hardware.
- frameworks/ml now builds, as does external/srec
- frameworks/opt, frameworks/ex and frameworks/wilhelm don't
build because of their dependency on frameworks/av.
frameworks/av should probably be dropped out of the blacklist
and replaced by individual markers on targets that we want
for 64 bit (we don't want all of them for arm64).
Change-Id: I9735108840fcba21ac8918bedf0d6de8989de086
This is until aosp gets the latest libpcap+tcpdump currently only on internal.
This reverts commit 5c68e265ac.
Change-Id: If6a990c72cb3a8d699cf0881f7d5fb8b725fdf2e
We'll probably remove external/oprofile soon, but this gets us closer
to being able to turn on an x86_64 continuous build in the meantime.
Change-Id: Ic1d5331d41dafee9ffed222dc332afed2d4ae356
Add four new variables for module makefiles:
LOCAL_MODULE_TARGET_ARCH specifies that a module is only supported for
one or more architectures. Any architecture not in the list will be
not attempt to build the module. The expected use case is prebuilts
that are only suitable for a single architecture, or modules like llvm
that need per-architecture support.
LOCAL_MODULE_UNSUPPORTED_TARGET_ARCH specifies that a module cannot be
built for one or more architectures.
LOCAL_MODULE_TARGET_ARCH_WARN and LOCAL_MODULE_UNSUPPORTED_TARGET_ARCH_WARN
are the same, but warn that the arch is not supported, which is useful
for modules that are critical but not yet working.
The logic for whether or not to build an architecture is fairly
complicated, so this patch consolidates it into module_arch_supported.mk
Change-Id: I120caf4a375f484e1fd6017b60c2f53882ae01e6
This isn't the same as chromium_org (which is used by the
webview). This is a 3 year old snapshot of the net stack which
compiles under 64 bit. It's currently used on aosp master by
libstagefright_chromium_http.
This project can be removed if the changes that remove the
chromium dependency are cherry-picked to aosp/master.
Change-Id: I5d0f9ed03ea9842b47d980d77ea32bc7a3f6998f
Previously HOST_TOOLCHAIN_PREFIX can't accept toolchain in arch-os-*-gcc
format. Fix it so we can try out new host toolchain, eg.
HOST_TOOLCHAIN_PREFIX=prebuilts/gcc/linux-x86/host/x86_64-linux-glibc2.11-4.6/bin/x86_64-linux- make
Change-Id: Ic1092593036c41d5471e788654fb4e0991dd7e40
