Currently when using sanitizers and building for the device
the -fsanitize= argument is not passed to the linker so that the
linker won't add the runtimes, which have already been added
as explicit dependencies. Pass -fno-sanitize-link-runtime instead
in case the linker has other behaviors when passed -fsanitize=
besides adding the runtimes. Also check for bionic instead of host
so that linux bionic gets the same linker behavior as bionic for
the device.
Test: m USE_HOST_MUSL=true host-native
Test: m checkbuild
Change-Id: I0f2966e2fd4ae8adc5cb21eb116c349bcc0c668f
This will suppress warning like:
system/chre/chpp/app.c:637:3: warning: Call to function 'memset' is insecure
as it does not provide security checks introduced in the C11 standard.
Replace with analogous functions that support length arguments or provides
boundary checks such as 'memset_s' in case of C11
[clang-analyzer-security.insecureAPI.DeprecatedOrUnsafeBufferHandling]
Test: WITH_TIDY=1 CLANG_ANALYZER_CHECKS=1 make tidy-system-chre-chpp_subset
Change-Id: I87a7bba31aa10260fc408317a8cd54bf80c03152
Bug: 215541108
Test: Build libcrypto with Bazel and verify the hash injected, add unit
test
Change-Id: I0375307aab0b1e60a8be298d680e1e0af1ebb454
Change-Id: I9133ce398e2024fe7834a292bf2f5ba3222d630b
Currently error messages appear like:
&fs.PathError{Op:"open", Path:"..." Err:0x18}
which make them difficult to parse.
Test: CI
Change-Id: I18da18abc43230d0ea37d166179d07e585077f51
* Work around RBE preprocessor bug, which rejects double dash flags.
Bug: 217778010
Test: make tidy-soong_subset
Change-Id: Ic7c0a95ae7afefb49cc9d124fd3c9f38fe2e0f56
This flag has never done anything for ld.lld, since it has this behavior
by default (and actually can't turn it off either). It's now being
removed as a valid flag from ld.lld, so it's time for Android to drop
the unnecessary flags. See https://reviews.llvm.org/D118942.
Test: builds
Change-Id: I22c344b7a55e275c1fbd5fef25f85e97a39de5c4
In case there are two vendor apexes(one with "use_vndk_as_stable:true",
and the other with "use_vndk_as_stable:false") a VNDK lib used by both
will have "APEX" variant and the former APEX will use "apex" variation.
For example,
apex1(use_vndk_as_stable) -> foo -> libvndk
apex2 -> bar -> libvndk
Since foo, bar and libvndk are mutated into two APEX variations("",
"apex10000"), foo will use the apex variation of libvndk.
To fix this, VNDK libs can use "unique" APEX variations. Then, in the
above example, foo will have "myapex1" variation and libvndk will have
two APEX variations("" and "apex2"). So foo will link to ""(non-APEX)
variation as fallback.
Bug: 216847402
Test: m nothing (soong tests)
Change-Id: I116932860ef79e22dc338a58b251e3ca693ab4f3
Soong modules that are specific for the host platform (e.g.
java_library_host, cc_binary_host, java_genrule_host, etc.) should
not be built on the target platform (Android), so we add a
target_compatible_with attribute to skip this type of module on an
Android target build.
Bug: 215229742
Test: go test ./bp2build
Change-Id: Ifb76ef4e0dc4cb3adb6a64b5c375ce36f7973e48
To unblock mixed builds, uses a common mechanism to determine cc module
type across bp2build and mixed builds.
Test: mixed_droid.sh
Change-Id: I1f69ad0858cda549b7c95dbadd596e46df0f23b2
