* changes:
Introduce inject_bssl_hash library property.
BoringSSL FIPS build - introduce extraLibFlags and use for STL libs.
Allow linker scripts when building objects.
Allow .o files as srcs.
external/boringssl needs to run a tool on a shared library, but
cc_genrules currently don't support shared libraries as inputs
or outputs. Use a property to trigger the desired behavior for
now.
Bug: 137267623
Test: m libcrypto
Change-Id: I75b4a761f8a4f2c65a99453d2781d6d0f93106ef
Rationale: On non-bionic, stl.go currently adds system libraries to
ldFlags, this causes problems for partialLd rules. However adding the
same libraries to libFlags breaks some existing modules due to symbol
conflicts as the system libraries are linked before some module code.
Introduced a general mechanism for adding libraries to be linked
last rather than making this STL-specific.
Bug: 134581881
Bug: 137267623
Test: TH
Change-Id: I779f28c6586b3fea85cc6299b686e4fde95262d3
This change adds 'no_apex' property which, when set to true, prevents
the module from being installed to any APEX. If the module is included
either directly or transitively in an APEX, but build fails.
Bug: 139016109
Test: m
Change-Id: If1478aa9660a3442f7dd1ffe45e4ca5611a6acbe
This reverts commit cba311bcfc.
The build is actually still broken with ASAN globals instrumentation.
We accidentally suppressed ASAN by turning on the new pass manager and
the build breakage was not discovered.
Bug: 137312732
Bug: 139747256
Change-Id: I8110e1413468c4d760a59a8de816a72c9852a7c8
Otherwise tools built with ASAN can't symbolize their dumps, as
llvm-symbolizer is not allowed to be used from $PATH.
Fixes: 139825736
Test: cherry-pick https://android-review.googlesource.com/c/platform/system/tools/aidl/+/1106532
mmma ASAN_OPTIONS="" SANITIZE_HOST=address system/tools/aidl
Change-Id: Ib1eeec15ce6694d7bde54c7201b3280e38df3a83
ASAN build has some weird issues with the new pass manager, keep using
the legacy pass manager for now.
Test: presubmit
Bug: 139747256
Change-Id: I345afbf6bc4043f274a4e7545a895b59c65641b0
"use_vendor: true" APEX modules may bundle vendor variants of cc
modules, which can depend on llndk stubs.
In that case, those llndk libraries should be also counted as required
libraries. (stored in 'requireNativeLibs' key in apex_manifest.json)
Bug: 138695532
Test: m nothing (runs soong tests)
Change-Id: If7ad4dec0e723c8d0c73ca60453b555063e14694
Treat proto.type: "javamicro" as a plugin by explicitly passing the
path to protoc-gen-javamicro. This allows removing the javamicro
customizations from the core plugin code.
Bug: 117607748
Test: m checkbuild
Change-Id: I703a8c1b788d77dcf6c656e79cab1c02171aa94e
java_import can be included in apex via 'java_libs' property.
Bug: 139175488
Test: m (apex_test.go updated)
Change-Id: I3680a47cdac93b0cb2d41da8df3f8defa2bbe670
When the native coverage is enabled, APEXes (and files there) are built
for native coverage as well.
Bug: 138952487
Test: make -j NATIVE_COVERAGE=true COVERAGE_PATHS='*' com.android.resolv
find out -name "*.gcno" | grep DnsResolver shows files
Test: libnetd_resolv.zip is found under
$(TARGET_OUT)/apex/com.android.resolv/lib directory
Change-Id: I97bcee9bf8ffc0dc71453abbdb613ed56ea2cdb4
For remote builds, we actually need to know that we depend on all
outputs from a genrule, not just the first one. But having every user
depend on every genrule output increases the ninja file size by >40%.
So to work around the increase in file size, use a ninja phony rule to
produce a single alias to all of the files. Unlike make, where phony
rules are always dirty, ninja does not attempt to stat phony rules as
long as they have inputs, so they act as an alias. (If they don't have
inputs, it will stat the file an only consider it dirty if it doesn't
exist.)
My remote build tooling can then see that it's a phony rule with inputs,
and collapse all of these inputs onto the actual rule.
This only applies to genrules that have >6 outputs, in order to keep the
graph simpler and easier to read for the common case. That's ~10% of the
genrules in AOSP, and it increases the ninja file size by ~1.3%.
Test: manual ninja file inspection
Test: treehugger
Change-Id: I1a26a02fe983f0c92ce726ada3133707223e662e
libclang_rt.builtins has default visiblity set to public and is the
last included static library for all modules. This means that it is
possible for libraries to pick up libclang_rt.builtins from their
shared library dependencies, instead of libclang_rt.builtins directly.
Particularly, a vendor prebuilt in AOSP was picking up __floatditf()
from libhidlbase.so instead of from libclang_rt.builtins. A change to
libhidlbase.so that removed the symbol caused thos prebuilt to fail to
link at runtime.
Bug: 138809247
Test: build, boot internal
Test: don't see libclang_rt.builtins symbols in libhidlbase.so
Merged-In: I0348c4860fe02cf88cb89f7ab356bd8c17826d77
Change-Id: I0348c4860fe02cf88cb89f7ab356bd8c17826d77
We've been getting these dependencies transitively through the
dependency on the object itself (which is a workaround for the lack of
dep file support in these tools). But for remote builds to work, we need
to know about these dependencies like any other object compilation.
For regular builds, this increases the size of the ninja file by a few
tens of megabytes (~1-2%).
WITH_TIDY builds were already larger (~40-50%), but are now about 90%
larger than a normal build.
Test: treehugger
Change-Id: Icdb4ca3d4d08d5706593d96d5c627149fa14fed8
Treehugger Robot