This properly sets -format=gnu for all non-Darwin targets, because
llvm-ar is cross-platform (but defaults to the host environment).
Bug: http://b/71618641
Test: m checkbuild
Change-Id: Ib5d1c112a4ac792a11d1a0721ae6b0a5f9a42727
This architecture only existed for unbundled use, but even the NDK is
removing support in their r17 release, so just remove support for it.
Test: build/soong/build_test.bash -only-config
Test: check buildserver configs, I don't see anything still using armv5
Change-Id: Ic183b510c9ada94438bd4cc2b9362fa438a29ced
llvm-ar is required for platform LTO build.
With GNU ar, we used crsPD flags, however 'P' flag is not supported by
llvm-ar. Since none of the platform archive files are built using third
party AR, the 'P' flag should not matter to us. However we've been
relying on one side-effect of 'P', where 'ar foo.a some/path/to/obj.o'
when foo.a already has a file named 'obj.o' will be an append operation,
regardless whether the existing one is the same (ar has no way of
telling the difference). We workaround this by always appending ('q'
flag) for llvm-ar. This may result in larger intermediate archive files
(more duplication) but will not affect the final build result.
Bug: 71618641
Test: m checkbuild
Change-Id: Id96a244cfe49cecfba08cc868dd18934ecb4ff23
The Java PATH fixup is now handled within soong_ui, along with the
values of ANDROID_JAVA_HOME based on OVERRIDE_ANDROID_JAVA_HOME /
EXPERIMENTAL_USE_OPENJDK9.
Mark PATH as deprecated, so that any reads/writes will cause warnings.
This will be switched to obsolete once it's verified that there are no
more users.
Using PATH within Kati means that we've got to rebuild the ninja files
whenever your PATH changes, which is not ideal, especially since some of
the envsetup functions can change your PATH. In most cases you only need
to use PATH within the bash portions of the build rules ($${PATH}), which
isn't treated as a make variable, so won't produce an error.
I'm also planning on replacing PATH in a future change with our own
directory that has placeholders for everything in your PATH. This will
let us remove tools that shouldn't be used from the build.
Test: m nothing
Test: build/soong/build_test.bash on AOSP and internal master
Change-Id: I18d8d19cfba313ff9176345bf73ac34e8dbebfbb
Default to ANDROID_COMPILE_WITH_JACK=false when TARGET_BUILD_APPS
is set.
Test: m -j TARGET_BUILD_APPS=Gallery2
Change-Id: Ibd2bdac6c7e2c4e2c6107fd35bd049fc8cb8dafe
Use TARGET_JAVAC and HOST_JAVAC exported from soong.
Test: m -j checkbuild
Merged-In: Ic094174149ea304c0b06ddc023417acf3602d5a3
Change-Id: Ic094174149ea304c0b06ddc023417acf3602d5a3
(cherry picked from commit 204dd14a2c)
This reverts commit 7de79cbeaf.
Fixed CTS build issue by adding -march=armv7-a in cts/tests/tests/os/jni/Android.mk since the library built here needs/uses instruction (swp) obsolete in ARMv8.
Bug: 64964151
Test: lunch aosp_arm64-userdebug; make -j cts
lunch aosp_x86-userdebug; make -j cts
lunch aosp_sailfish-userdebug; make -j cts
lunch aosp_bullhead-userdebug; make -j cts
Change-Id: Ic3a121600da8e2a9a2d5176b9680cd18ce457959
Overwrite TARGET_(2ND_)ARCH_VARIANT as armv8-a if
TARGET_(2ND_)CPU_VARIANT is set to some known armv8-a core like
cortex-a53, cortex-a73, kryo, denver64 etc.
For clang, -march is ignored if -mcpu is set to specific core so this
change doen't impact the objects built for armv7-a-neon/some_armv8_core
since it's treated as armv8-a/some_armv8_core.
Bug: 62895439
Test: Built modified aosp_arm64 with armv8-a as its TARGET_2ND_CPU_ARCH
and generic as its TARGET_2ND_CPU_VARIANT successfully.
"lunch hikey-userdebug; make" and verify TARGET_2ND_ARCH_VARIANT
is overwritten.
Change-Id: If4260cf397783b5f56c4fd432615f4676429a1d3
Android bundles an OpenJDK-derived toolchain to avoid issues with
unsupported toolchains. For development / experiment purposes, this
CL the toolchain to be overridden via OVERRIDE_ANDROID_JAVA_HOME.
It is an error for OVERRIDE_ANDROID_JAVA_HOME to be set but not
point to a valid toolchain, but this error is not explicitly
checked for.
Bug: 38177295
Test: Treehugger
Change-Id: I72f641f560501e498f9c86a4380f19941fca11ad
Export JAVA_HOME as an absolute path to commands running inside
a build.
Should fix errors invoking gradle from inside a build:
ERROR: JAVA_HOME is set to an invalid directory: prebuilts/jdk/jdk8/linux-x86
Please set the JAVA_HOME variable in your environment to match the
location of your Java installation.
Test: treehugger
Change-Id: I16e4482b2d74ede0843715be3b08c65ce33cf403
Point the make java variables at JDK prebuilts in
prebuilts/jdk/jdk8, add them to the path, and clean up
some old overrides.
Reapplies Ibbeb30fab96e45aedd5bb6d710d1170f85789982 after updating
some more manifests to include the prebuilts.
Bug: 62956999
Test: m -j checkbuild
Change-Id: I9e27aa5cb04d1ed09e43b798e5d654843afc000f
(cherry picked from commit 1931750940)
Point the make java variables at JDK prebuilts in
prebuilts/jdk/jdk8, add them to the path, and clean up
some old overrides.
Bug: 62956999
Test: m -j checkbuild
Change-Id: Ibbeb30fab96e45aedd5bb6d710d1170f85789982
Compiling Dialer requires increasing the javac heap size above
1GB, probably due to the extensive use of annotation processors.
Increase it to 2GB.
Test: m -j ANDROID_COMPILE_WITH_JACK=false
Change-Id: I4dd3759a98ea915469e69f563dc49be8a25d518e
Merged-In: I4dd3759a98ea915469e69f563dc49be8a25d518e
(cherry picked from commit 0e785c79b8)
Replace java -> $(JAVA), etc. to prepare for moving java binaries
out of the path and using full paths to them.
Test: builds
Bug: 62956999
Change-Id: I5dfcd0d4e855ecde69cd127169e9545e59723d12
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
