This change fixes following problem:
1) a native lib having stubs is defined.
2) the lib is included in an APEX.
3) a static binary is linking the lib from outside of the APEX.
4) then, the dependency from the binary to the lib is vanishing.
This is happening because cc.depsToPaths() mistakely does not
distinguish static lib deps from shared lib deps. For shared lib deps,
it creates two dependencies (one for stubs variant and the other for
non-stubs variant) and choose the stubs variant when the lib and the
current module is not in the same APEX (i.e. dependency to the non-stubs
variant is discarded). However, since we don't have stubs variant for
static library, it ends up having no dependency to the library if the
link is static.
Fixing the issue by skipping the variant selection routine when the link
is static.
Test: m (apex_test added)
Test: build with https://android-review.googlesource.com/c/platform/bionic/+/849044
Change-Id: I21102a31cc5c0b105da2affdd035bd5cc571a6ab
use_vendor, when set to true, brings vendor variant of the native
libraries and binaries to the APEX.
Bug: 115707625
Test: m (apex_test updated)
Change-Id: Ib4e996f8652f4ce4645a9c22f6914e2ab35edda6
The dependency is added because the module that uses the sysprop library
needs generated code before it is built.
Test: m -j
Change-Id: I2858fc6fa6f2fe16afa2f4a7ae62746ba0f67e5c
Ie42edc5184f315f998db953594e425214b810e0e added system_shared_libs to
static libraries so that their exported headers can be referenced.
However, it also added unrequired dependencies, which is an
error-triggering issue for static executables.
This change addresses it by adding a condition to shared libs handling code
in binary.go.
Bug: 121152570
Test: cc_test.go, library_test.go
Change-Id: I1828442c4e496f8d815fccaeca970cd5766bdf5d
Now, symbols that are only to be visible to across APEXes can be tagged
as # vndk. Then when generating the stubs library, the tagged symbol
is included. The symbol is NOT included in other cases; build NDK stubs,
etc.
Bug: 120638081
Test: m (apex_test updated.)
Change-Id: Idb2b552badddfc26af113cc8d4b984788f478813
If a symbol is tagged as # apex, then it is exported when gen_stub_libs
is invoked with --apex.
Bug: 120638081
Test: python3 cc/test_gen_stub_libs.py
Change-Id: I190bca35d1a4fb422b37d1be41a34de1ad64de6b
Otherwise, the force included headers might cause conflicting types
error with the symbols in the generated stubs source code. e.g.
double acos(double); // in header
void acos() {} // in the generated source code
Bug: 120266448
Test: m (apex_test also updated, and passing)
Change-Id: I717df990959d1b24ec515f0f52a4e28b94e92f32
The runtime APEX is built for host as well as for target. Therefore
stubs libs should be available also for host.
Bug: 120670568
Test: follow the repro step shown in b/120670568#comment4
Change-Id: I350fe490848ae9ceb55aade0521bdfaf48ed083f
This change fixes a problem that APEX variations are created for the
modules that actually shouldn't built for any APEX. For example,
consider this case.
apex { name: "myapex", native_shared_libs: ["mylib"],}
cc_library { name: "mylib", shared_libs: ["libfoo#10"],}
cc_library { name: "libfoo",
shared_libs: ["libbar"],
stubs: { versions: ["10"], }, }
cc_library { name: "libbar", ...}
Before this change, both the stubs and non-stubs variations of libfoo
were mutated with apexMuator, which is incorrect for the non-stubs
varia; there is no dependency chain from the apex "myapex" to the
non-stubs variation, but to the stubs variation due to the #10 syntax.
This was happening becauses we used the name of the module to determine
whether it should be built for APEX or not. Both stubs and non-stubs
variations have the same module name "libfoo".
Fixing this issue by recording the list of APEX variations required
directly on the module. So, the stubs variation of libfoo has myapex in
its apex variations list, but the non-stubs variation doesn't, and thus
apexMutator does not pick up the non-stubs variation.
Test: m (apex_test updated and passing)
Test: cherry-pick ag/5747464 and m
Change-Id: I31e618626809a828a55fff513ef5f81f79637afa
When the stubs variant of a library is dependend by a platform component
and the library is included in one or more APEX, the library is not
installed to the platform, because it is provided by APEX.
Bug: 120266448
Test: m
Test: add stubs: { versions: ["1"], }, to libnetd_resolv
then build netd. libnetd_resolv.so does not exist under /system.
Change-Id: I09b78e38df285033ef6e9c85f7ea4b0274e85070
Add a no_recover option that allows specifying which sanitizers in
diagnostics modes shouldn't recover. This can help debugging as we test
enabling sanitizers in new libraries since it'll cause tombstones to be
generated along with the diagnostics information.
Bug: 80195448
Bug: 110791537
Test: Compiled test module with this flag, checked compiler command.
Test: Test module crashed, tombstone contained diagnostics information.
Change-Id: Ie938923ef95716c2d49d6cd719ee223ad62755c6
Stubs libs are build-time only artifact. Can't be installed.
Test: OUT_DIR=out build/soong/scripts/build-ndk-prebuilts.sh
with https://android-review.googlesource.com/c/platform/frameworks/av/+/846770/7
and two more CLs in the same chain
Examine out/soong/build.ninja
Build rule for out/soong/target/product/generic_arm64/system/lib64/arm64/libmediandk.so
exist only once.
Change-Id: I58ff09ef3fbbdbd2d968aa21b87a493192d4216d
Stubs libs are not built with dependencies required for cfi and stl.
Also it does not make much sense to build stubs with cfi and stl because
the libs are not for runtime and there is no C++ symbols.
Test: cherry-pick ag/5747464 and m
Change-Id: I83d6d82513a77a6a8a345e7d12707940c2c906c7
Current implementation does not play nice with -gc-sections.
Bug: 120673911
Test: make SANITIZE_TARGET=hwaddress recovery-persist
Change-Id: I36cd37fb41c0c26c7e747e2c1dd5fadf7a31f4e7
* Now header-abi-dumper does not complain about -fno-sanitize=implicit-integer-sign-change
Bug: 119558057
Test: make checkbuild
Change-Id: I80be08dd5aa184498bdbb83b42b877dbec152165
Not all projects can be built when their base directory (the
directory containing the Android.bp file) is automatically included.
For example, external/jsoncpp has a file named version, which will
override the standard library's <version> header.
It would maybe be reasonable for this to be on by default, but many
projects in the tree currently depend on this behavior.
Test: make checkbuild
Bug: None
Change-Id: I58dff2689270ae56fef7cf83be31262d16794fc4
This is needed to build libicui18n on Windows, as it depends on APIs
created in Windows 7 (ResolveLocaleName).
Test: sdk build
Change-Id: If64510a262f7f1d4d356b1a9960ceea114cfa78a
This reverts commit 4f0ce757aa.
Reason for revert: Breaks several targets in internal git_master, e.g. http://ab/5165971.
Test: Build failing library
Change-Id: I02a5ade05a76b24020586c55a4e8f441ca7708a9
Add dependencies for source modules when they are referenced in
library.Shared/Static.Srcs. Use ExpandSources to expand filegroups
for these properties.
Bug: http://b/120534727
Test: make
Change-Id: I58d02d8f7d60026abbcde75298c7a61b27bdbf12
* Add -fno-sanitize=implicit-integer-sign-change when
there is any integer related sanitizer, and this check
is not explicitly specified.
Android core does not boot with this new sanitizer yet.
* Filter out -fno-sanitize=implicit-integer-sign-change
from tooling flags.
Bug: 119329758
Bug: 119557795
Test: make checkbuild, boot, go/clang-r346389-testing
Change-Id: I709de569cb73d070fc4958e2b4387f4041bc5438
