Introduce cc_api_library, which reflects imported API from other
inner-tree. This cc_api_library module type will later refer from
the other ninja module which generates stub library from the interface
description.
Tested environment :
* original libc definition has been removed temporarily, to ensure that
imported api stub library is being used from build
* Added new definition of libc as below
cc_api_library {
name: "libc",
arch: {
x86: {
src: "libs/x86/libc.so",
},
x86_64: {
src: "libs/x86_64/libc.so",
},
},
header_libs: [
"libc_headers",
],
export_header_lib_headers: ["libc_headers"],
min_sdk_version: "9",
vendor_available: true,
}
Bug: 236087698
Test: `ALLOW_MISSING_DEPENDENCIES=true m vendorimage` succeeded
Change-Id: I67070b0f3561aa2afd73b6c1c0fdf4255218baac
Test: Built AFL fuzzers individually and built all using haiku command
and built libfuzzers individually and also by using haiku command. Ran
selected fuzzers manually to ensure fuzzing still worked.
Description: Previously we needed to add cc_afl_fuzz to build an afl fuzz binary,
however, to turn current libFuzzers into AFL fuzzers this would required
an update to each Android.bp file which is a lot of work, and would also
require an approval from each Android.bp file owner, which is even more
work.
To get around this (and also to match how AFL fuzzers are built in G3)
we will build AFL++ fuzz binaries by command line option FUZZ_FRAMEWORK.
When FUZZ_FRAMEWORK=AFL is set, all cc_fuzz modules will be built
for AFL rather than libFuzzer. Devs can also specify if a cc_fuzz module
is only for libFuzzer or AFL by using fuzzing_frameworks. If
fuzzing_frameworks is left blank then it will be assumed that the
cc_fuzz module can be built for all available fuzzing frameworks.
Change-Id: If57d3038f05e52775177eaeb26f8ed2bdc73443a
A new module libcrypto_for_testing was added that uses the
inject_bssl_hash property, but this property is currently only available
for the libcrypto module specifically.
Test: CI
Change-Id: I1b83de02a2990b7503980bf6a85611683427baf9
Revert submission 2164482-Build AFL from Command line option
Reason for revert: Unit test fails on MAC builds
Reverted Changes:
Ia7a822462:Updated the way we build AFL++ fuzz binaries
I994bde63b:Updated the way we build AFL++ fuzz binaries
Ie863853b4:Updated the way we build AFL++ fuzz binaries
I577d6ae7b:Updated the way we build AFL++ fuzz binaries
Ic4fd34f8d:Updated the way we build AFL++ fuzz binaries
Change-Id: Ic2cda7733d206d7ed178f1db5e38268bc915e57b
Some code compiles with -Werror, which makes it very hard to mark
anything as deprecated without breaking the build. This option
will ensure that we can still mark things as deprecated without
breaking such code. Among other things, this will allow us to
undo a local change to protobuf which disables deprecation
warnings.
Bug: 203713560
Test: presubmit
Change-Id: I718de31c3ff685dba4104f3c9e7bd5d169d89f7e
Test: Built AFL fuzzers individually and built all using haiku command
and built libfuzzers individually and also by using haiku command. Ran
selected fuzzers manually to ensure fuzzing still worked.
Description: Previously we needed to add cc_afl_fuzz to build an afl fuzz binary,
however, to turn current libFuzzers into AFL fuzzers this would required
an update to each Android.bp file which is a lot of work, and would also
require an approval from each Android.bp file owner, which is even more
work.
To get around this (and also to match how AFL fuzzers are built in G3)
we will build AFL++ fuzz binaries by command line option FUZZ_FRAMEWORK.
When FUZZ_FRAMEWORK=AFL is set, all cc_fuzz modules will be built
for AFL rather than libFuzzer. Devs can also specify if a cc_fuzz module
is only for libFuzzer or AFL by using fuzzing_frameworks. If
fuzzing_frameworks is left blank then it will be assumed that the
cc_fuzz module can be built for all available fuzzing frameworks.
Change-Id: Ia7a8224627f2de61606b410d1d1a56d7bdc0955f
In the newly proposed Cross-Verison ABI Check, the path of dump that
LLNDK, NDK and mainline reference to is changed to:
Before finalization: current/
After finalization: {PLATFORM_SDK_VERSION}/
In addition, a related CL(aosp/2147882) modifies the script to create
dump to folders that match the current finalization stage.
Test: make libbinder_ndk
Bug: 238387082
Change-Id: I92a4a52c26c85cf4c866b441e54291c6a624fbf4
filtering out no longer useful flags in bp2build conversion
Test: cc_library_shared_conversion_test
Bug: 231995978
Change-Id: I5172f6d07a8928291bbc11bd8802678b33cc5b1f
Some build targets pulls cflags from build/soong but has its own choice
of compiler version. This causes errors for due to unknown warning
options. This allows them to suppress such checks.
Test: presubmit
Change-Id: Ia89508d6b92481fb1ed0c90f1fdb4d8e54566349
Previously, the symbol tag `# apex` was treated the same as `#
systemapi`. With this CL, they have different meanings.
`# systemapi`: APIs that are defined in the platform (the non-updatable
part), and are exposed to unbundled system components like APEX
`# apex`: APIs that are defined in the APEX and are exposed to the
platform or other APEXes
Bug: 239274367
Test: m
Change-Id: I0484ea349656dbbd337e5fe3a5970f0ad275b807
Introduce the class `Filter` which encapsulates conditions
(architecture, api level, whether llndk is included, etc.) so that we
don't need to touch many places everytime a new condition is added.
In addition, refactor test_symbolfile to reduce duplications
This CL doesn't add a new functionality.
Bug: 239274367
Test: run test_ndkstubgen and test_symbolfile
Change-Id: I188e482492d39ec18134ecc5c908f0d288a754a9
The staging compiler update sometimes needs additional cflags to build, but those flags may not be recognised by the current compiler. Add a
new `llvmNextExtraCommonGlobalCflags` section and only append those
flags when LLVM_NEXT is set.
Test: LLVM_NEXT=true m
Bug: 236798112
Change-Id: Icc4687950acd44798b2cf09131a425ddfd919214
Revert submission 2124256-AFLpp support in Soong
Reason for revert: It is breaking the build
Reverted Changes:
Ie07ec3368:Adding support for building AFLpp Test: Build AFL ...
I5bd6d1e9b:Adding support for building AFLpp Test: Built AFL ...
Change-Id: Id2eec1060f7532fec46293d0c207be800e6eaa03
Since vndk libraries don't need to maintain Cross-Version abi
compatibility. The newly proposed Cross-Version ABi checking mechanism
is applied to only ndk/ and platform/. The reference dumps of LLNDK
libraries should get from platform/ to be benefited from this checking
mechanism.
Test: mkdir -p prebuilts/abi-dumps/platform/UpsideDownCake/64/x86_64/source-based/ && cp prebuilts/abi-dumps/vndk/32/64/x86_64/source-based/libvndksupport.so.lsdump "$_"
make libvndksupport -j
Bug: 238383845
Change-Id: I663511d60623cd23619166d8d63fd26220a930e2
This is to avoid hitting command-line length issues when building with
RBE enabled for C++ links.
TESTED=ran a build with link actions and saw command-line getting
shorter in size from verbose.log
Bug: b/237480728
Change-Id: Id66165159388554bb76579080c5a6979dd670d22
* changes:
Pass -fno-sanitize=vptr,function for musl
Use musl rust prebuilts for USE_HOST_MUSL=true
Don't package host cross modules in javaFuzzPackager
Add rust musl arm and arm64 toolchains
The prebuilts for musl have the necessary symbols for vptr and function
sanitizers, but enabling them implicitly enables RTTI which causes RTTI
mismatch issues with dependencies.
Bug: 215802826
Test: m USE_HOST_MUSL=true host-native
Change-Id: I93edfd617d99efcac0eca58bb3f3c173c4fa121a
There are 3 different properties about exporting headers in Soong:
1. export_static_lib_headers
2. export_shared_lib_headers
3. export_header_lib_headers
The static and header cases are already supported in bp2build but
do not have tests. This CL adds support for the shared case and
adds tests for all cases.
Fixes: 236268577
Test: Unit tests
Change-Id: Idfb788271e607919d4ac6bc0e4eb4e6ff8f78e8d
Don't use hwasan for non-bionic arm64 targets, including
arm64-linux-musl and arm64 darwin.
This relands I67c07f26f25a9f9807ee21ee79c113ea11f65473 which was
accidentally reverted in I47a9322929baff2492c6e8db989ece01fcbeb133.
Bug: 236052820
Test: build arm64 musl sysroot
Change-Id: I77753ecb6f07aafa1b6e00ad6bf432f9c9744f79
This CL fixes a bug when Soong pass `-target` with a non-digit suffix in Clang. As mentioned in b/236753843, Clang's version parsing expects to see an integer in the target string so it ignores the
S suffix.
Test: m gwp_asan_crash_handler && make sure -target is aarch64-linux-androidS instead of aarch64-linux-android31
Test: go test -run ^TestNonDigitMinSdkVersionInClangTriple$ android/soong/cc
Bug: 236753843
Change-Id: I258ecc52083dbf3471d23cf310e0ad54440f1908
Allow listing rust_ffi_shared modules as a jni_libs dependency
in conjunction with platform_api: true. This allows inclusion by
android_app modules.
Bug: 237304791
Test: android_app module builds with a rust_ffi_shared dependency.
Change-Id: I3a28e1baa522ad8f9c2aa86f1d23b19ce9f967e1
Add toolchains to support cross compiling to aarch64-linux-musl and
arm-linux-musleabihf.
Bug: 236052820
Test: build arm and arm64 musl sysroots
Change-Id: I47a9322929baff2492c6e8db989ece01fcbeb133
