cc_library_static {
name: "libfoo",
shared_libs: ["libbar"],
}
cc_library {
name: "libbar",
}
If libfoo is part of an APEX, then libbar is no longer considered as a
member of the APEX, because it isn't actually linked to libfoo.
To distinguish such a shared lib dependency from a static library from a
shared lib dependency from a shared library, a new dep type
SharedFromStaticDepTag is introduced. It is treated exactly the same as
SharedDepTag, except when we determine whether a dependency is crossing
the APEX boundary or not.
This allows us to check the apex_available property more correctly.
Previously, modules were incorrectly considered as being used for an
APEX due to the shared lib dependency from a static lib.
As a good side effect, this also reduces the number of APEX variants.
Specifically, on aosp_arm64, the number of the generated modules were
reduced from 44745 to 44180.
Exempt-From-Owner-Approval: cherry-pick from internal
Bug: 147671264
Test: m
Merged-In: I899ccb9eae1574effef77ca1bc3a0df145983861
(cherry picked from commit 931b676a69)
Change-Id: I899ccb9eae1574effef77ca1bc3a0df145983861
This change fixes a bug that apex_available is not enforced for static
dependencies. For example, a module with 'apex_available:
["//apex_available:platform"]' was able to be statically linked to any
APEX. This was happening because the check was done on the modules that
are actually installed to an APEX. Static dependencies of the modules
were not counted as they are not installed to the APEX as files.
Fixing this bug by doing the check by traversing the tree in the method
checkApexAvailability.
This change includes a few number of related changes:
1) DepIsInSameApex implementation for cc.Module was changed as well.
Previuosly, it returned false only when the dependency is actually a
stub variant of a lib. Now, it returns false when the dependency has one
or more stub variants. To understand why, we need to recall that when
there is a dependency to a lib having stubs, we actually create two
dependencies: to the non-stub variant and to the stub variant during the
DepsMutator phase. And later in the build action generation phase, we
choose one of them depending on the context. Also recall that an APEX
variant is created only when DepIsInSameApex returns true. Given these,
with the previous implementatin of DepIsInSameApex, we did create apex
variants of the non-stub variant of the dependency, while not creating
the apex variant for the stub variant. This is not right; we needlessly
created the apex variant. The extra apex variant has caused no harm so
far, but since the apex_available check became more correct, it actually
breaks the build. To fix the issue, we stop creating the APEX variant
both for non-stub and stub variants.
2) platform variant is created regardless of the apex_available value.
This is required for the case when a library X that provides stub is in
an APEX A and is configured to be available only for A. In that case,
libs in other APEX can't use the stub library since the stub library is
mutated only for apex A. By creating the platform variant for the stub
library, it can be used from outside as the default dependency variation
is set to the platform variant when creating the APEX variations.
3) The ApexAvailableWhitelist is added with the dependencies that were
revealed with this change.
Exempt-From-Owner-Approval: cherry-pick from internal
Bug: 147671264
Test: m
Merged-In: Iaedc05494085ff4e8af227a6392bdd0c338b8e6e
(cherry picked from commit fa89944c79)
Change-Id: Iaedc05494085ff4e8af227a6392bdd0c338b8e6e
cc_library_static {
name: "libfoo",
shared_libs: ["libbar"],
}
cc_library {
name: "libbar",
}
If libfoo is part of an APEX, then libbar is no longer considered as a
member of the APEX, because it isn't actually linked to libfoo.
To distinguish such a shared lib dependency from a static library from a
shared lib dependency from a shared library, a new dep type
SharedFromStaticDepTag is introduced. It is treated exactly the same as
SharedDepTag, except when we determine whether a dependency is crossing
the APEX boundary or not.
This allows us to check the apex_available property more correctly.
Previously, modules were incorrectly considered as being used for an
APEX due to the shared lib dependency from a static lib.
As a good side effect, this also reduces the number of APEX variants.
Specifically, on aosp_arm64, the number of the generated modules were
reduced from 44745 to 44180.
Bug: 147671264
Test: m
Change-Id: I899ccb9eae1574effef77ca1bc3a0df145983861
This change fixes a bug that apex_available is not enforced for static
dependencies. For example, a module with 'apex_available:
["//apex_available:platform"]' was able to be statically linked to any
APEX. This was happening because the check was done on the modules that
are actually installed to an APEX. Static dependencies of the modules
were not counted as they are not installed to the APEX as files.
Fixing this bug by doing the check by traversing the tree in the method
checkApexAvailability.
This change includes a few number of related changes:
1) DepIsInSameApex implementation for cc.Module was changed as well.
Previuosly, it returned false only when the dependency is actually a
stub variant of a lib. Now, it returns false when the dependency has one
or more stub variants. To understand why, we need to recall that when
there is a dependency to a lib having stubs, we actually create two
dependencies: to the non-stub variant and to the stub variant during the
DepsMutator phase. And later in the build action generation phase, we
choose one of them depending on the context. Also recall that an APEX
variant is created only when DepIsInSameApex returns true. Given these,
with the previous implementatin of DepIsInSameApex, we did create apex
variants of the non-stub variant of the dependency, while not creating
the apex variant for the stub variant. This is not right; we needlessly
created the apex variant. The extra apex variant has caused no harm so
far, but since the apex_available check became more correct, it actually
breaks the build. To fix the issue, we stop creating the APEX variant
both for non-stub and stub variants.
2) platform variant is created regardless of the apex_available value.
This is required for the case when a library X that provides stub is in
an APEX A and is configured to be available only for A. In that case,
libs in other APEX can't use the stub library since the stub library is
mutated only for apex A. By creating the platform variant for the stub
library, it can be used from outside as the default dependency variation
is set to the platform variant when creating the APEX variations.
3) The ApexAvailableWhitelist is added with the dependencies that were
revealed with this change.
Bug: 147671264
Test: m
Change-Id: Iaedc05494085ff4e8af227a6392bdd0c338b8e6e
Some additional, possibly arch specific, properties need adding to
cc library (e.g. recovery_available). This dedups and cleans up the
code involved to simply the addition of those new properties.
Bug: 142918168
Test: m nothing
Change-Id: I0963aa02e9504af1ae9b427ff1016e7c481465f4
When SOONG_ALLOW_MISSING_DEPENDENCIES is set, it should be OK to miss
shared library variants.
Test: master-art manifest, use bionic stubs
Bug: 142935992
Change-Id: Ie0054acfef7c4406594a87378a7029380a9fda50
If CFI is enabled for a module, no-vendor-variant VNDK will fail
because CFI is not used for the vendor variant.
Bug: 148638729
Test: Remove libstagefright_bufferpool@2.0 from the whitelist. Build on
crosshatch is successful. Build on a ARM32 device with
TARGET_VNDK_USE_CORE_VARIANT set and check no-vendor-variant VNDK
is still enabled for libstagefright_bufferpool@2.0.
Change-Id: Ib0a411d7ea769097186afa802751b0796527ec76
module_bp_cc_deps.json was not written through
android.WriteFileToOuptutDir, so it didn't get the absolute path
prepended when sandboxing was turned on. Reuse the implementation
from module_bp_java_deps.json.
Bug: 147409906
Test: m SOONG_COLLECT_CC_DEPS=1 nothing
Change-Id: I3b255bdfd3b4c442db06fe185765414905531410
This flag indicates that the sample profile data matches the source
and can be fully trusted. The compiler will make aggressive
assumption that functions without any samples are cold functions,
and will optimize for size for them.
Test: binary size reduces to match instr PGO
Bug: 79161490
Change-Id: I53d6d05be70c39e5eb28b2f5b0549d9eb6b5cc62
Pattern initialization helps us make C++ safer, while not altering the
semantics/usage of C++ (as zero init does).
Bug: 131390872
Test: Local testing. Parts of CTS.
Change-Id: Ic4af9260a48c10cbd70315fa56d6b01c5ca61768
Otherwise binaries under:
prebuilts/gcc/linux-x86/host/x86_64-w64-mingw32-4.8/bin/
are being invoked.
https://sourceware.org/binutils/docs-2.33.1/binutils/windres.html
states:
When windres reads an rc file, it runs it through the C preprocessor first.
Use the `--preprocessor` flag to specify the exact command to run. The
args to the preprocessor get wiped out when setting that flag, so
`-E -xc-header -DRC_INVOKED` must be re-passed, else clang will error as
it tries to invoke ld.
Once AOSP packages llvm-rc, aosp/1206346 can be rebased on top, so this
patch should be a short lived change.
Bug: 147295872
Test: <remove mingw gcc> && lunch aosp_x86-eng && \
cd external/mdnsresponder && mm
Change-Id: Ic0e6b75e7e964ee9f9757e534cddd16438604c34
Suggested-by: Pirama Arumuga Nainar <pirama@google.com>
Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
These libraries don't have a core variant against which to check
for identicalness.
Bug: 148526685
Test: built a previously failing target with this change (succeeded)
Change-Id: Ide8ec58df1868175f52c005bf73bb81fc196a571
This lets us test uninitialized variables even if we change the defaults
for -ftrivial-auto-var-init.
Bug: 131390872
Test: AUTO_UNINITIALIZE=true m
Change-Id: I2b4473a0547dc9c4d9f081d8af2d283f17f66f7a
This is to support enabling scudo only for non-svelte configs.
Also, add exclude_static_libs to allow removing the jemalloc libs.
Bug: 137795072
Test: Verified that a svelte and non-svelte config can use this method
Test: to properly choose between scudo and jemalloc.
Change-Id: Iec6bfe159f8491138e93dde1d225a8c874c7ce31
This CL adds RBE support to javac, r8, and d8 rules which is only
enabled if respective environment variables are set.
Test: an aosp_crosshatch build with and without the new variables.
Change-Id: Ic82f3627944f6a5ee7b9f3228170c2709b1bfcb8
aidl libs need to be differentiated because they explicitly set
different system/vendor stabilities.
Bug: 142230898
Test: fixes build
Change-Id: Ib09baa946faff8334f7c50568db5e6735dfbbfe2
