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
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
It can detect and support 3 different scenarios:
- 32-bit exe / 32-bit OS
- 64-bit exe / 64-bit OS
- 32-bit exe / 64-bit OS
Change-Id: I799a91277a5e2331aebf4b2f031e9a79f7ab5bb0
Ying Wang