Switch from `PathForModuleSrc` to `PathForSource`. The latter does not
check that the target path exists in the tree. This is necessary since
the prebuilt stub and header directories are not guaranteed to exist
when Soong analysis begins (Step 2a)
Build orchestrator will be responsible for putting these files in the
right place as part of Multi-tree ninja invocation (Step 4)
Test: go test ./cc
Change-Id: I27175a8440fca6bba21197b1e106a22b733da882
The build uses unstripped binary/shared library to extract function
signatures, so for each each target of this kind Bazel should return
its unstripped version, too.
Fixes: 220164721
Test: treehugger
Change-Id: Id5f6143340519bf2ae98791a9e981d1306bb08d1
Bug: http://b/248022906
Bug: http://b/247941801
HWAsan global instrumentation on __llvm_profile_filename causes
duplicate symbol errors when linked together with libraries where hwasan
is disabled. Disable hwasan global instrumentation since those type of
errors are rare.
In the future, we may fix this in llvm to skip hwasan global
instrumentation on symbols added for coverage.
Test: m CLANG_COVERAGE=true NATIVE_COVERAGE_PATHS=* \
SANITIZE_TARGET=hwaddress
Test: Add `hwaddress: true` to libc_defaults; m CLANG_COVERAGE=true
Change-Id: I8506cfd567d212262a2a54b9881a8f64cdbf7a76
create_minidebuginfo doesn't support riscv64 yet, disable stripping
for riscv64 until it does.
Test: m ALLOW_MISSING_DEPENDENCIES=true LLVM_PREBUILTS_VERSION=clang-r468909b LLVM_RELEASE_VERSION=15.0.3 libc -k
Change-Id: Iaad7ec0e4befe1652b413e20a7095cdde56d57bc
Enable cc_prebuilt_binary to also take part in mixed builds.
Bug: 241415823
Test: TestPrebuiltBinaryWithBazel
Test: mixed_droid yields stats-log-api-gen under bazel-out/
Change-Id: I18b2906c91ea90370ab851a1287c2890546d633f
Otherwise we hit an unknown --arch error in ndkstubgen as soon as we try
to build an NDK library (such as libc/libdl/libm, which are the very
first libraries we need to build).
Test: treehugger
Change-Id: Id633248d1fa80eeddfd234301355931bb1309dc3
The module types in scope of this conversion are
1. cc_library and cc_library_shared (non-null llndk or stubs prop)
2. cc_library_headers (all)
For (2), we need some postprocessing on the results of the parser
bp2BuildParseBaseProps. This is necessary because arch and os specific
API exports need to be flattened and added to the generateed API headers
target along NoConfigAxis
e.g.
```
The api equivalent of
cc_library_headers (
name = "lifoo",
deps = select({
"//build/bazel/platforms/arch:arm": ["arm_deps"],
"//build/bazel/platforms/arch:arm64": ["arm64_deps"],
}),
)
should be
cc_api_library_headers (
name = "lifoo",
deps = ["arm_deps", "arm64_deps"],
)
```
For (1), we also need to generate 1:many header api targets so that
arch-specific deps can propagate arch metadata to the top-level
api_domain rule
Test: go test ./bp2build
Test: go test ./cc
Change-Id: Ie40cba1ac8e89f290b3d926c190d5e93abd52859
I49220cbec628f1508709741dc56b62aaac7786d9 attempted to allow
apexes to depend on native code whose min_sdk_version had been
increased to meet the minimum supported API level for a new
architecture. It wasn't quite right, as it assumed that the
primary architecture of the apex would be the newest, and
it applied to all dependencies, not just ones that were
specfiic to the new architecture. Move the checking into
cc.ShouldSupportSdkVersion, where it can be specific to an
individual architecture variant.
Bug: 250918230
Test: TestApexMinSdkVersion_MinApiForArch
Change-Id: I303cf485ba54b4c6bf63a9f9b49286ff9b2c9c83
Allow external/vendor owners and toolchain developers
to run clang-tidy with external/vendor files,
by setting TIDY_EXTERNAL_VENDOR=1 or true
instead of touching .bp or .go files.
Bug: 244631413
Test: TIDY_EXTERNAL_VENDOR=1 make tidy-soong_subset
Change-Id: I0c903f32eb0e5daa0f8dfa2f6dc892b8f8c4ebcc
* changes:
Move fuzzer's CollectAllSharedDependencies into GenerateAndroidBuildActions
Support AllowMissingDependencies in prebuilt_apex modules
Support AllowMissingDependencies for apex dependencies
Add AllowMissingDependencies support for prebuilt_etc module with no src property
Make OutputFileForModule work for AllowMissingDependencies
Fix panics when target arch is riscv64
Apexes for new architectures have to increase their minSdkVersion
to the minimum supported version for the architecture.
Bug: 250918230
Test: lunch aosp_riscv64-userdebug && m ALLOW_MISSING_DEPENDENCIES=true nothing
Change-Id: I49220cbec628f1508709741dc56b62aaac7786d9
Make rust and cc fuzzers collect their shared libraries once in
GenerateAndroidBuildActions and store it for later use by the
packaging singleton. Also use android.OutputFileForModule to get
the paths. Together this will fix fuzzers that depend on architecture
specific prebuilt shared libraries that are missing a prebuilt for an
architecture when building with AllowMissingDependencies.
Bug: 250918230
Test: lunch aosp_riscv64-userdebug && m ALLOW_MISSING_DEPENDENCIES=true nothing
Change-Id: I154a6f3a767c883e9fe7067003615db73ee78e2d
Currently, tagging a symbol with #apex is not required when the symbol
is in a non-NDK library. However, this is considered dangerous because
such a symbol will automatically be promoted to NDK APIs when the
library is promoted to an NDK library. When that happens, the native API
council won't be able to notice the promotion because promoting a
non-NDK library into an NDK library doesn't require an update of the
map.txt file, but Android.bp only.
To prevent that, we should mandate #apex (or #systemapi if the api is
provided by the system, not apex) tag for Mainline APIs regardless of
whether the library the API belongs to is an NDK library or not.
Bug: 184712170
Test: m
Change-Id: Iad589b606bc6ed06ef1237f4c9f0c22518b0db75
By default, ndkstubgen does not omit NDK symbols as long as they
satisfy the API version and the CPU architecture requirements. This
change adds a new flag --no-ndk to ndkstubgen which is used to
override the default behavior. If the flag is set, NDK symbols are
omitted leaving only the annotated symbols (e.g. #apex, #systemapi,
etc.).
This will be used for stub libraries that are not part of NDK. So far,
symbols in such libraries haven't needed to be annotated as #apex, and
that has caused a confusion that those symbols belong to NDK. The
follow-up change will ensure that those symbols are always annoated as
either #apex or #systemapi so that their roles are clearly visible.
Bug: 184712170
Test: atest test_ndkstubgen
Test: atest test_symbolfile
Change-Id: Ic8d2c7d0b32bdef79f7563621035e60f406e4131
* This is a temporary work around until the RBE input processor
can handle those flags.
* It's okay to remove some cflags in clang-tidy command
if they do not affect tidy check results.
Bug: 248371171
Test: enable RBE; RBE_CLANG_TIDY_EXEC_STRATEGY=remote; make tidy-soong_subset
Change-Id: If499bd7e1f0f89ccc3b7f7df7d67cfc64dc67028
Fix panics in api_level.go and apex.go when using riscv64 as the target
arch.
Bug: 250918230
Test: lunch aosp_riscv64-userdebug && m ALLOW_MISSING_DEPENDENCIES=true nothing
Change-Id: I85c7685f3d14fa2dc7ffbcdea7f490feca304ef7
The module types in scope are
1. ndk_library
2. ndk_headers, versioned_ndk_headers
3. api_domain
These modules will no longer generate Bazel targets in bp2build
workspace. A new soong mode `api_bp2build` will be used to generate API
specific targets in a separate Bazel workspace at out/soong/api_bp2build
Test: go test ./bp2build
Change-Id: I01d06b6d8b8364c0d56d6d3f07f8f8bf21db31d7
Overrides properties will now be captured in json flag files, which will
be copied to installed vendor snapshot modules.
Bug: 216567575
Test: soong test && manual install
Change-Id: Ife5e84b126e798fba7802b9cff000c9197756cb9
Context
- Android-<target>.mk currently does not contain information about partition for its dependent unembedded jni libraries, but only lists the name of the unembedded jni libraries.
- If an android_app module depends on an unembedded jni library that is located in a different partition, make cannot find the library.
Implementation
- Create a string field partition in jniLib struct.
- Add variable "LOCAL_SOONG_JNI_LIBS_PARTITION_<target>", an array of mappings of the name of the jni library to its partition.
Bug: 154162945
Test: m
Change-Id: I6b8e1272ff59dc70e3dd6ce8c6c8e4686dad76df
But do the splitting before adding $(location...) flags.
Fixes: 247830974
Test: Unit tests
Test: m nothing
Change-Id: I4a7e8e20f720a1074a5ffa17da4fe9b96ca6ed58
Add barebones riscv64-linux-android support. This should be enough
to add riscv64-specific entries to Android.bp files, but can't
actually compile anything until there are riscv64 toolchains.
Test: arch_test.go
Change-Id: I0dcc7e797d9352dd38243be908a7f19004ff3db1
Remove Toolchain.GccRoot, Toolchain.GccVersion, and Toolchain.GccTriple
that were only used by an unused function. This removes most of the
references to GCC, although there are still some left in the host
toolchains.
Test: No change to build.ninja for aosp_cf_x86_64_phone-userdebug or aosp_raven-userdebug
Change-Id: I72b8af1f9aa83e6e15c9e00ed1e817b6cc3a031a
