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
[Second attempt, this time with updated mac prebuilt]
Switches default linker from -fuse-ld-bfd to
-fuse-ld=gold, and enables -Wl,--icf=safe. This
changes reduces /system/lib64/*.so text size
by about 2% for N9.
Change-Id: I587075aae9d70cb6b16e55dc9cd1052580ac2626
When a shared object is rebuilt, all dependent libraries and
executables are rebuilt. Such rebuild is unnecessary when there
is no interface change. With this patch, .toc files will be
generated for all .so files. The rule which generates .toc files
has ninja's restat=1 and .toc files are not changed ninja won't
rebuild dependent targets.
Performance:
$ m && touch bionic/libc/stdio/stdio.c && time m
Before: 1m03s (2563 targets)
After: 21s (90 targets)
Bug: 24597504
Change-Id: Ia5dd950273d143f4e99eee8bef7478f1a94cd138
Causes build failures on Darwin.
prebuilts/gcc/darwin-x86/aarch64/aarch64-linux-android-4.9/aarch64-linux-android/bin/ld.gold: warning: cannot scan executable section 5 of out/target/product/flounder/obj/SHARED_LIBRARIES/libdl_intermediates/libdl.o for Cortex-A53 erratum because it has no mapping symbols.
prebuilts/gcc/darwin-x86/aarch64/aarch64-linux-android-4.9/aarch64-linux-android/bin/ld.gold: warning: cannot scan executable section 8 of out/target/product/flounder/obj/SHARED_LIBRARIES/libdl_intermediates/libdl.o for Cortex-A53 erratum because it has no mapping symbols.
prebuilts/gcc/darwin-x86/aarch64/aarch64-linux-android-4.9/aarch64-linux-android/bin/ld.gold: warning: cannot scan executable section 11 of out/target/product/flounder/obj/SHARED_LIBRARIES/libdl_intermediates/libdl.o for Cortex-A53 erratum because it has no mapping symbols.
prebuilts/gcc/darwin-x86/aarch64/aarch64-linux-android-4.9/aarch64-linux-android/bin/ld.gold: error: treating warnings as errors
This reverts commit 127d110172.
Change-Id: I1d3de90f5ae777b66a8f94fbcc9ccde8a9e3001c
Switches default linker from -fuse-ld-bfd to
-fuse-ld=gold, and enables -Wl,--icf=safe. This
changes reduces /system/lib64/*.so text size
by about 2% for N9.
Change-Id: I0ef2483e1c47c34e63292dad6f6bf532359b733e
gcc color diagnostics stopped working when the flag was moved to
TARGET_GLOBAL_CFLAGS, as that gets overwritten by combo/select.mk. Put
it back in COMMON_GLOBAL_CFLAGS, and then let the windows build filter
it out, similar to the way clang deals with unknown flags.
Change-Id: I2db221edb893d81f199494e7515d1b9282c12fae
The darwin version doesn't have a trailing slash. The common case is to
append a path to it:
$(HOST_TOOLCHAIN_FOR_CLANG)/lib/...
Which means we end up with two slashes.
Change-Id: I74e88924ecfd092c5f7871e188ede0aab29cf65b
There will only be a very small set of non-uapi headers. This is
mostly being done for the scsi headers since the kernel has not
made uapi versions of all of them.
Change-Id: I44904b07ff96de918dc5fcab4e5f117a34cb2a87
shamu checkbuilds set USE_CLANG_PLATFORM_BUILD, which shouldn't apply to
modules built for windows. Also fix some flags that were being set
improperly.
Bug: 23566667
Change-Id: Id4c5b7cc59966328483d90f2b7be3f35e439ecee
Instead of using recursive make to change the HOST_OS when building the
windows SDK under linux, add the concept of cross-building to another
host os.
Bug: 23566667
Change-Id: I6dc525b601b6251d458d197c30bf4660d7485502
- Added GLOBAL_JAVAC_DEBUG_FLAGS and merge it to
PRIVATE_JAVACFLAGS/PRIVATE_JACK_FLAGS to get rid of
PRIVATE_JAVAC_DEBUG_FLAGS/PRIVATE_JACK_DEBUG_FLAGS.
- With Java rules out of base_rules.mk we can get rid
of java_alternative_checked_module now.
Change-Id: I1a14716c785e3d49330a75044107662ce96a9307
Turns out that thanks to 9d59f41776 we actually
build *all* the host libraries both 32- and 64-bit. Rather than fix the
libraries (or fixing things so we don't build stuff we don't need) right now,
let's just put _FILE_OFFSET_BITS and _LARGEFILE_SOURCE back.
Change-Id: I6c2d6a6919d1518f775e0d6c050e2c774994c5bd
This reverts commit b8dd176441.
This wasn't the problem, and mingw doesn't even use _LARGEFILE_SOURCE. The real problem (using WIN32 instead of _WIN32 in external/llvm) is fixed now.
Change-Id: I2b708a006b530cb18d03b1425cd65edda35ee17e
I forgot that removing a file doesn't cause a rebuild in our lame build
system, so I hadn't actually tested my previous change.
Change-Id: Ida19d4a8fd40e37029031eac4b4ca5f0cc5c895b
The only things left that we're using are the Windows target version
and _FILE_OFFSET_BITS=64, and they can go in the combo .mk.
Also fix the unused Windows 64 .mk.
Change-Id: I5f2458d67c0a8201196a339573f861bbf18b7eb8
We still support HOST_OS=windows for the SDK host tools cross-builds, but
that's only when USE_MINGW is set when running under linux.
Change-Id: I37da87dc9fbbd69ba10ce4d7f2668ab3f6482d92
The transitive symbol resolving causes build breakage when a binary
has indirect dependency on the NDK library.
This matches the change made for the the aarch64 toolchain:
https://android-review.googlesource.com/#/c/120654
Change-Id: Id5b2a63301cb1cdcdd84b4bcd9fbec8cf6ec0b3c
Dan Willemsen