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
* commit '3bbaab31069045aea9ae33c1d995640e56182a82':
support LOCAL_MODULE_TARGET_ARCH for prebuilts
Add generated sources dir to the default include path
* commit '054b0274fc27babb42a60002ad25c9e608eac257':
add support for more LOCAL_*_arch variables
don't rename 32-bit executables to *_32
remove 2nd arch from ARCH_ARM_* defines
Depending on the file extension of the generated C++ file,
bison will generate a #include of a .h or .hpp. So both files
must be kept in the generated directory.
Change-Id: Id0aac7f407bdc69c7f5012c0d021761b0fceb427
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
- 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
Include apps that appear under /system/priv-app
to also be included with the zip of all the apps.
Change-Id: If4687cf4c471877f11d78b68bad96f1842e49d87
Signed-off-by: rpcraig <rpcraig@tycho.ncsc.mil>
Also we don't need to include module_arch_supported.mk again, if we are
currently substituting the source build with LOCAL_PREBUILT_MODULE_FILE.
Change-Id: I444b0397d74c3153b398a050b762e49418062a86
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
So a library can export the proto's include path that can be used with
both archs in multilib build.
Change-Id: Ia0f92f0b40e39dc3fa426c69c52139a0a8f04077
For host executables and shared libraries, the global LDFLAGS were being
inserted into the linker command line after the module-specific ones,
making it impossible to override the default settings. Change the order
to match target linker invocations.
Change-Id: Icd5f6f83df9f27a5be97ddb197ee245c1ab8c2be
This makes sure copy_headers.mk only be included onces, no matter
it's for the 1st arch or the 2nd arch.
Change-Id: I80a558fbdb52861f176bd27a21c302069a5cc3ce
It seems the code was meant to add the toolchain to ANDROID_BUILD_PATHS
and then export to PATH by lunch.
But now we export the toolchain to PATH explicitly in envsetup.sh and
the code is unnecessary.
This reduces the places to change when we upgrade the gcc version.
It also fixed the bug that the mips toolchain was always exported
regardless of the target arch.
Change-Id: Iee3b895b4c4e0df8971c27c01b9ecbd591848b12
Fix several wrongly configured tests that were either
looking for tests in the wrong jar (apache-harmony-tests
instead of core-tests) or using the wrong prefix.
Also, this change creates subsets of the harmony tests based
on subpackage names (java.net, java.io, java.nio etc.) instead
of the earlier harmony groupings.
Change-Id: Iea0e20d23512611d1aac92b2f8219031b6396c77
Prebuilts often support only a single architecture, allow them to
use LOCAL_MODULE_TARGET_ARCH to specify it.
Change-Id: I2514f66f682ef267bbf1a1ab78510faff0a18b64
The LOCAL_*_$(TARGET_ARCH) variables don't make sense for host
modules, only append use them for target modules.
Also complete the list of LOCAL_*_arch and LOCAL_*_32/64 to be
consistent.
Change-Id: I00c83e5c4e08ed9a844f9f99a79ce4bcc3f0bf11
combo/TARGET_x86*.mk mistakenly added TARGET_GLOBAL_CFLAGS to their
linker command lines. This results in clang builds not working properly,
since they strip some unknown flags from TARGET_GLOBAL_CFLAGS.
Change-Id: I60a1ff5df70305323134435e4ae107ea7acfe8ea
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
-- Added TARGET_PREFER_32_BIT, which sets LOCAL_32_BIT_ONLY for an
executable, if LOCAL_NO_2ND_ARCH is not true.
Name resolving in 64-bit multilib build:
-- Name resolving in PRODUCT_PACKAGES:
foo:32 resolves to foo_32;
foo:64 resolves to foo;
foo resolves to both foo and foo_32 (if foo_32 is defined).
-- Name resolving for LOCAL_REQUIRED_MODULES:
If a module is built for 2nd arch, its required module resolves to
32-bit variant, if it exits;
Otherwise for executable and shared library, a required module
resolves to the default 64-bit variant; for other module classes,
required module foo resolves to both foo and foo_32 (if foo_32 is
defined)
Bug: 12898862
Change-Id: I5fda1a77f58814097b10b5ad2743ee25adfaecc4
Ben Cheng