This is a partial revert of commits:
858657366f Remove support of disabling Jack.
3ae7861252 Remove javac support in host dex rules.
22313f2b2a Remove rules for building dex with dx
Test: builds
Change-Id: Ie12d743cbe978bdeb030910848b67f5945a4fec8
Remove the global linker search path, as it can cause spurious build
failures. If a library with the same name as a system library is in the
process of being written to the directory in the global search path, and
the linker may try to read the partially-written built one instead of the
system one. We already use full paths to libraries for target builds,
do the same for host builds. Also remove the normalize library
functions, they are no longer necessary.
Test: m -j checkbuild
Bug: 31393456
Change-Id: If9fc631e111f568c700fd73e103445c30d7e9d11
On mips64r6 builds, the shell variable ARCH_MIPS_REV6 is not
cleared before compiling 2nd arch parts. This bug is harmless when
2nd arch is mips32r6 but it omits needed mips-specific assembly
files when compiling libagl and libpixelflinger for mips32r1 or r2.
Clearing the variable is impractical. Using TARGET_2ND_ARCH qualifiers
would work, but Arm and x86 use a simpler method with distinct ARCH_ARM
and ARCH_ARM64 symbols. ARCH_MIPS_REV6 is used in two places.
Both controll 32-bit parts only, so neither place needs adjustment.
Change-Id: Id1ea5e8b6f8666d9df219fa9ef41834bd31f5dd8
These are all either recently unused due to the removal of CFLAGS/etc,
or have been exported by Soong and are no longer necessary.
Change-Id: I5930d43fda21acc8202b3d8ea010fbefb6ae4cf1
Host native tests have been getting installed into
out/host/linux-x86/bin/..., but this pollutes the bin directory with a
lot of poorly named tests. Also, to support 32-bit and 64-bit tests, we
need to have different names with different suffixes. This causes
problems when tests expect to be named something specific (like gtest).
It's also convenient to store test data next to the test itself.
So with this change, native tests will be installed in
out/host/linux-x86/nativetest[64]/$(LOCAL_MODULE)/$(LOCAL_MODULE_STEM)
just like target tests get installed into /data/nativetest[64].
Implement this using a new NATIVE_TESTS class, which is like
EXECUTABLES, but sets up the install path differently, and configures
the rpath to load shared libraries with the proper relative path.
LOCAL_MODULE_RELATIVE_PATH can be used to control the directory name, it
will default to $(LOCAL_MODULE). This way multiple related tests can be
grouped together.
Target native tests also use NATIVE_TESTS now, but nothing should change
other than LOCAL_MODULE_RELATIVE_PATH can be used.
Change-Id: I535e42b1a6b21c5b8d6a580aa2f944d2be35e27d
At the beginning of every build, Soong has exported its version of these
variables, and has been ensuring that when sorted, the result is the
same. So these variables all have the same flags of the Soong ones, but
may be in different orders. We don't believe any of the remaining order
differences matter. As we remove the Make definitions, the exported
Soong variables will take over.
This only removes lines that change one of these variables:
[2ND_][CLANG_]HOST_CROSS_GLOBAL_CFLAGS
[2ND_][CLANG_]HOST_CROSS_GLOBAL_CONLYFLAGS
[2ND_][CLANG_]HOST_CROSS_GLOBAL_CPPFLAGS
[2ND_][CLANG_]HOST_CROSS_GLOBAL_LDFLAGS
[2ND_][CLANG_]HOST_GLOBAL_CFLAGS
[2ND_][CLANG_]HOST_GLOBAL_CONLYFLAGS
[2ND_][CLANG_]HOST_GLOBAL_CPPFLAGS
[2ND_][CLANG_]HOST_GLOBAL_LDFLAGS
[2ND_][CLANG_]TARGET_GLOBAL_CFLAGS
[2ND_][CLANG_]TARGET_GLOBAL_CONLYFLAGS
[2ND_][CLANG_]TARGET_GLOBAL_CPPFLAGS
[2ND_][CLANG_]TARGET_GLOBAL_LDFLAGS
Many other variables are unnecessary now too, but those will be removed
in another change. For those we can ensure the build.ninja file does not
change, but we expect it to change here due to the ordering differences.
Change-Id: I0bd0778706d02ee27b2784dd8dc6b2c71d37bd3a
Soong does not have the idea of global linking directories, so move the
windows prebuilt library directory to GLOBAL_LDFLAGS instead.
Change-Id: Ie101146f4682cd85924463aa5acaa46869938e6c
We never use it for host modules, and all the target configurations use
the same linker argument. This matches Soong.
Change-Id: Ibcba9a4ce340c7a12306d1fee620a04027c0e292
These have all been strictly checked by Soong, so the values currently
match. Just remove them so that the make variables exported by Soong
will take over.
This also removes some of the GCC reconfiguration, since we haven't
implemented that in Soong. If it becomes useful in the future, we'll
implement it there.
Some things like TARGET_TOOCHAIN_ROOT can nearly be removed, but are
used before the Soong-exported make_vars.mk is loaded. In that case,
added to the clang cflags, so it can be removed once the cflags are
removed.
Others, like LLVM_PREBUILTS_VERSION are loaded even earlier -- in
envsetup.sh before we've even configured Soong. So for now, keep the
Make definition, and continue ensuring it's the same as the Soong
version.
Change-Id: I554b27062ac43610828a8c06d640d919a2dc21ca
Instead, use the libgcc/libatomic/libgcov from the static libraries dir,
which is provided by Soong. Copy the libraries using the Soong script if
Soong is disabled - this can be removed once USE_SOONG is removed.
Change-Id: Iad2ad20ad5c3cfc48bf1e46e594a482609098d7a
The current 32-bit configuration for generic x86_64 targets inherits some
variables (SSE4 support) from the 64-bit configuration, and overrides
the make variables used for other configurations (SSSE3). Ideally, these
would be using different variables, but until then, unify the
configuration for x86_64 targets so that everything is consistent.
Bug: 28694691
Change-Id: I47e67299d4c632e7491d7e73dc0fc6480ef08006
This flag was added to stop a GCC 4.4 specific warning. Since we've
upgraded, this flag is no longer necessary. It's already stripped for
clang builds, and I found no instances in the logs after removing it.
Change-Id: If5316d2eb8066dc43d7af7aebc7e4920b4ada192
We removed code and variables related to running dx on classes.jar in
this change. Also removed target emma rules (but kept the emma rules for
host java libraries), for it's now done by Jack.
We still support to build classes.jar (and javalib.jar for static Java
libraries) using javac, because tools like javadoc need class files as
input.
Removed the obsolete install-dex-debug.
Bug: 27400061
Change-Id: If0bcdfe62cb181a98754fb0dbe1c12c92e38d3e8
Soong uses the copy of `ar` in the OSX SDK instead of the wrapper in
/usr/bin/ar. /usr/bin/ar appears to be a thin wrapper that looks up the
current SDK and passes execution to it. Soong does this so that it can
actually set up a dependency on the tool.
Change-Id: Ia4e4fbe3287539933fa98a1354c3ccee91f4d552
Build binaries usable on older machines even if older SDKs are not
installed. Older SDKs can no longer be installed on newer Xcode
versions.
Change-Id: I0c9f2534466a127a19107820879c2856bfac0076
We've been including the system libc++ headers even if we're building
against our version of libc++. Stop doing that, and only add the headers
to our path if we're using the system libraries.
If nothing is specified, on recent OSX versions, libc++ is the default
c++ library instead of libstdc++. We've been explicitly including the
libc++ headers on all versions, but that breaks old versions. Force us
over to libc++, since the system libstdc++ does not support C++11, and
libc++ is still supported on our oldest version (10.8).
Change-Id: I1fccee8da0f425e10ccc9d3247ed40664eb6ada0
/Developer was removed in Xcode 4.3. Our minimum SDK version is 10.8,
which implies at least Xcode 4.4, and our documentation requires
Xcode 4.5.2.
Change-Id: Ib343df6ded6e98222d8ee2e542e1f3fadd2b1397
Sandy Bridge actually doesn't have all of these options. For example AVX is only
available on the higher-end SKUs (not on Celeron G550).
Change-Id: Ib595a9a6b464626d0c88525c6aaa4d69176645cc
* When WITH_STATIC_ANALYZER is set and non-zero, and clang compiler is used,
call new clang ccc-analyzer or c++-analyzer.
* Otherwise, if WITH_SYNTAX_CHECK is set and non-zero,
call compiler with -fsyntax-only.
* Replace "--sysroot=path" with "--sysroot path", to work with ccc-analyzer.
* ccc-analyzer executes the original compilation command to generate
object files before calling clang with --analyze to do static analysis.
* When clang is called with --analyze, macro __clang_analyzer__ is defined.
BUG: 13287788
Change-Id: I5edb25b52998d871385dd000778db2ce83224078
This is mostly the same as the existing 2ND_HOST / HOST_CROSS support.
The interesting thing I did here was make x86 the 'first' architecture,
and x86_64 the second. This way LOCAL_MULTILIB := first defaults to
32-bit windows modules.
windows-x86/bin <- defaults to 32-bit executables
windows-x86/lib <- 32-bit libraries, like before
windows-x86/lib64 <- 64-bit libraries
windows-x86/obj <- 32-bit intermediates
windows-x86/obj64 <- 64-bit intermediates
Then modules are registered with the names:
host_cross_liblog <- 32-bit, like before
host_cross_liblog_64 <- 64-bit
Bug: 26957718
Change-Id: I9f119411acb43e973ec1e6bca3c1dc291c91556c
This change enables build rules to specify:
LOCAL_JAVA_LANGUAGE_VERSION := 1.8
to enable -source 1.8 -target 1.8 for javac and
equivalent flags for Jack.
Bug: 26753820
(cherry-picked from commit cdfbe4a852)
Change-Id: I361c99dd599e7b4a041f02c9562e461da2b0502e
Bug: http://b/26524325
Bug: http://b/25282907
The latest Clang/LLVM requires Vista APIs in order to execute, so we
need to bump the minimum required Windows version for our host tools.
Change-Id: Ic1a760bc240060f5de39ce3a68484886021ff3d9
Turn back on ld.gold and W-l,--icf=safe for
aarch64, now that the prebuilt ld.gold has been updated
with support for reloc 311/312 (fixed upstream, see
https://sourceware.org/bugzilla/show_bug.cgi?id=19042)
Bug: 25642296
Bug: 26153840
Change-Id: Idceb357a48d9da4eec38ab8f2103245d500622ae
Some projects are still built with our host GCC 4.8, which doesn't
support -fstack-protector-strong. The combo .mk files are used by
GCC and clang, so it's not safe to turn on -fstack-protector-strong
there. Instead, do it in the clang-specific .mk for now.
We can clean this up when elfutils (the last code built for the host
with GCC that I'm aware of) is built by clang. We'll be able to
remove the host GCC prebuilts too!
Change-Id: I314b9eab071c132a8e2cb8cc779a75ae8abb12e2
This results in nearly all functions with the possibility of stack
corruption getting stack canaries, because it applies to any function
taking a reference to the frame or with a local array rather than just
the functions with arrays larger than 8 bytes. It was developed for use
in Chrome (and Chrome OS) and has also been adopted by various other
distributions (Arch, Fedora, Ubuntu, etc).
The code size increase ranges from ~1.5% to ~2.5%, compared to ~0.3% to
~0.7% with the more conservative switch. The increase in the performance
loss is usually minimal. The overall size increase once everything other
than C and C++ code is taken into account is minimal, and it greatly
improves the mitigation of stack buffer overflow vulnerabilities.
https://lwn.net/Articles/584225/
Change-Id: I2fb7f0bfccbfa5d22ca8858309a133469edbc7b6
This results in nearly all functions with the possibility of stack
corruption getting stack canaries, because it applies to any function
taking a reference to the frame or with a local array rather than just
the functions with arrays larger than 8 bytes. It was developed for use
in Chrome (and Chrome OS) and has also been adopted by various other
distributions (Arch, Fedora, Ubuntu, etc).
The code size increase ranges from ~1.5% to ~2.5%, compared to ~0.3% to
~0.7% with the more conservative switch. The increase in the performance
loss is usually minimal. The overall size increase once everything other
than C and C++ code is taken into account is minimal, and it greatly
improves the mitigation of stack buffer overflow vulnerabilities.
https://lwn.net/Articles/584225/
Change-Id: Iccc20852db8a5e4dd9792f9da6d5e325fc59b0a5
This results in nearly all functions with the possibility of stack
corruption getting stack canaries, because it applies to any function
taking a reference to the frame or with a local array rather than just
the functions with arrays larger than 8 bytes. It was developed for use
in Chrome (and Chrome OS) and has also been adopted by various other
distributions (Arch, Fedora, Ubuntu, etc).
The code size increase ranges from ~1.5% to ~2.5%, compared to ~0.3% to
~0.7% with the more conservative switch. The increase in the performance
loss is usually minimal. The overall size increase once everything other
than C and C++ code is taken into account is minimal, and it greatly
improves the mitigation of stack buffer overflow vulnerabilities.
https://lwn.net/Articles/584225/
Change-Id: I3ce7a73c5cf36eba5c74df37367f3d3475b0a4ed
This results in nearly all functions with the possibility of stack
corruption getting stack canaries, because it applies to any function
taking a reference to the frame or with a local array rather than just
the functions with arrays larger than 8 bytes. It was developed for use
in Chrome (and Chrome OS) and has also been adopted by various other
distributions (Arch, Fedora, Ubuntu, etc).
The code size increase ranges from ~1.5% to ~2.5%, compared to ~0.3% to
~0.7% with the more conservative switch. The increase in the performance
loss is usually minimal. The overall size increase once everything other
than C and C++ code is taken into account is minimal, and it greatly
improves the mitigation of stack buffer overflow vulnerabilities.
https://lwn.net/Articles/584225/
Change-Id: I55a9fdbf5777ccdeed9f2e9a23c73bb94ad7b646
This results in nearly all functions with the possibility of stack
corruption getting stack canaries, because it applies to any function
taking a reference to the frame or with a local array rather than just
the functions with arrays larger than 8 bytes. It was developed for use
in Chrome (and Chrome OS) and has also been adopted by various other
distributions (Arch, Fedora, Ubuntu, etc).
The code size increase ranges from ~1.5% to ~2.5%, compared to ~0.3% to
~0.7% with the more conservative switch. The increase in the performance
loss is usually minimal. The overall size increase once everything other
than C and C++ code is taken into account is minimal, and it greatly
improves the mitigation of stack buffer overflow vulnerabilities.
https://lwn.net/Articles/584225/
Change-Id: I97a2187cebac64e3b9f22b691d4676b6da083ebd
Currently, if a version script is passed to the linker (using
-Wl,--version-script,...), it is used to limit symbol visibility and
assign symbol versions. But if a symbol is listed in the version script
but is not present in the binary, no error or warning is given.
Pass -Wl,--no-undefined-version to the linker so that it verifies all
(non-wildcard, C) entries in the version script match symbols in the
binary.
Change-Id: I65878931ab61124ae75e2c738cc733adfb107afc
